If the answer to the first prompt is 'NewWidget' then the default title should be 'New Widget' - I think this can be done by setting the default property of the title prompt to a function.

See: https://github.com/SBoudrias/Inquirer.js#question

Also, to break a string on the capital letters, see:

http://stackoverflow.com/questions/7888238/javascript-split-string-on-uppercase-characters

Also, we may want to replace the CSS prefix prompt with a prompt for base class that defaults to the dasherized widget name. That way users can override the default that we currently generate.

widget generator should work as is for 2d widgets

After #54, the app asks if the app is 2D or 3D. If we moved that prompt to after asking for the WABROOT and app, then we could know if it's 2D or 3D based on the app's config.json. We would still need to prompt the user for 2D or 3D in the case that "none" is selected on the "Web AppBuilder Application" prompt.

The theme generator use this._.classify to create a theme name that can be safely used as a folder name, but that can change the name from what the user originally input.

Instead, the prompt should use the same logic in the widget generator to validate whatever the user types and proceed as long as it's a valid folder name.

This will require updating the expected folder name in the tests.

Installing this on a clean machine it appears that mkdirp is not installed. I think it will be if it's moved from devDependencies to dependencies.

This is the instructions when running yo esri-appbuilder-js:

The generators should be run in the root folder of either the stem app or an app that you've already created with the Web AppBuilder.

But this is from the readme:

The generators should be run in the root of a working folder for your project. This should be outside of the Web AppBuilder's folder structure (i.e. NOT in the stem app or an app that you've already created with the Web AppBuilder). The grunt tasks configured by the generators will handle copying the widget files to the appropriate folders under the Web AppBuilder's install directory.

It would be nice if I, as a developer, could use my favorite CSS preprocessor and the gruntfile would automatically build that out into the CSS files for the widgets.

Just adding this as a placeholder for discussion.

should only touch parts of package.json that need to be modified (devDependencies).

I think the right thing to do is to not scaffold package.json from a template and just use npmInstall(), but I'm not sure what happens if there's no package.json when you do that.

See the following for context:
http://yeoman.io/authoring/composability.html
http://yeoman.io/authoring/dependencies.html

Many times when creating a new widget, you actually want to extend from an existing widget (Measurement, layer list, etc). Would be nice if that's an option in the generator.

I hear @gbochenek has been doing some research around this concept ... PRs welcome :) :)

Look at structure of 3d widgets in WAB 2.0 beta for differences (prob more than just the 2d/3d setting in manifest), and add a prompt that let's user choose 2/d/3d.

It's so easy for people to use eslint init or npm install semistandard to get exactly the rules they want instead of the JSAPI rules (which are targeting IE8, etc).

At the least we should:

• update the .jshintc template in this to the latest JSAPI rules
• not scaffold .jshintrc if a user chooses ES6
• If not ES6 prompt the user if they want to use Esri's .jshintrc? dunno

@sam-berg discovered that the 2D/3D properties are causing widgets not to show up in the select widget dialog in beta2:

Built in Query (works):

{
  "name": "Query",
  "platform": "HTML",
  "version": "",
  "author": "Esri R&D Center Beijing",
  "description": "",
  "copyright": "",
  "license": "http://www.apache.org/licenses/LICENSE-2.0"
}

Custom, Works:

{
  "name": "CommanderSearch",
  "platform": "HTML",

  "version": "0.0.1",
  "author": "Esri Boston",
  "description": "test",
  "copyright": "",
  "license": "http://www.apache.org/licenses/LICENSE-2.0",
    "properties": {
    "inPanel": true,
    "hasLocale": false,
    "hasUIFile": false,
    "hasStyle": false
  }
}

Custom, Does not work:

{
  "name": "CommanderSearch",
  "platform": "HTML",
  "2D":"true",
  "3D":"false",
  "version": "0.0.1",
  "author": "Esri Boston",
  "description": "test",
  "copyright": "",
  "license": "http://www.apache.org/licenses/LICENSE-2.0",
    "properties": {
    "inPanel": true,
    "hasLocale": false,
    "hasUIFile": false,
    "hasStyle": false
  }

}

Custom, Does not work:

{
  "name": "CommanderSearch",
  "platform": "HTML",
  "2D":"true",
  "3D":"false",
  "version": "0.0.1",
  "author": "Esri Boston",
  "description": "test",
  "copyright": "",
  "license": "http://www.apache.org/licenses/LICENSE-2.0",
    "properties": {
    "inPanel": false,
    "hasLocale": false,
    "hasUIFile": false,
    "hasStyle": false
  }

}

I generated a theme using default responses to all prompts and then copied to WAB v1.3 stemapp. I then createad a new app using the Default template and tried to apply the theme. I see this error in the console:

For example:

https://github.com/tomwayson/web-appbuilder-tools-techniques-dev-summit-2015/tree/master/src/demo

As demonstrated here: http://video.esri.com/watch/4568/arcgis-web-appbuilder-development-tools-and-techniques

Is anyone using this? @spohner, @g3r4n, @jPurush, @gavinr? Seems like the normal practice for creating a custom theme is to copy an existing one that is closest to the one you want to create. So I'm not sure that a generator based on a single theme even makes much sense.

Furthermore, there's an open bug #33 that I have no plan to fix, and I don't know of any contributors that are interested in maintaining the theme generator. This means it will be hard to continue to evolve this repo as long as we have to continue to work around the broken theme generator.

One idea is to consider merging #36 as a v2 (it requires a bump in the version of the yeoman-generator dependency to at least v0.17) - at which point we could make breaking changes, including dropping the theme.

cc @yiweima, @asizer, @qlqllu

Since v2.0.0 is a breaking change, might as well be on latest ver of yeoman-generator. Also, there is a very slight chance that we'll need this for #39.

Even if not, I'm almost certain that we'll want it for v2.1 so the default generator can store the user's ES6 preference for later use in the widget generator. So if this does not happen for v2.0 it will go into v2.1.

See the v0.18 blog post for info.

Currently only prompts for inPanel, but could prompt for all of the following and only build out the required files. Since all are booleans and default to true, could be done w/ one checklist prompt that defaults to checked, like:

[x] inPanel
[x] hasLocale
[x] hasStyle
[x] hasConfig
[x] hasUIFile
[x] hasSettingPage

If hasSettingsPage is checked, then could show a second prompt w/ the following (defaulting to answers from above for hasUIFile, hasLocale, and hasStyle):

[x] hasSettingUIFile
[x] hasSettingLocale
[x] hasSettingStyle

Based on the answers from above, the generator would create the appropriate files and update the properties object in manifest.json and clazz object as needed.

While this would be simple to implement (aside from basing the second pompt on answers from the first), writing tests for the un/checked state of each could be time consuming.

The settings page could just include a text box that allows the user to set the widget tittle/description?

The official name of the product is "ArcGIS Web AppBuilder" - need to update all references in the prompts, and docs.

Not planning on using any bower packages, so no need to scaffold bower.json etc.

Answer will determine:

• output folder (stemapp or stemapp3d)
• default path to wab root folder (use current for 2d, if 3d, default to ...\WebAppBuilderForArcGIS)

Store response to 2d/3d for use in widget generator. See this blog post and PR.

As of beta 2, the stemapp includes a template for custom widgets. The files scaffolded out by the widget generator should be consistent w/ the template files. I think for the most part they are except for Widget.js.

Should work like the custom widget generator.

(either blank or a number) instead of hardcoding appDir to 2
add docs explainign this and possibly encouraging creation of test app ahead of time

see #36 for context as to ultimate goal (prompt by app name) - maybe it makes sense to go all the way at this point?

Hi guys,
Any thoughts why this is happening?

It returns:
>> Invalid path. Please ensure this is a valid path to your WAB root.

See: http://docs.travis-ci.com/user/getting-started/

Currently the app (default) generator only captures the author and inserts it into package.json. It should also capture copyright and license to be used by sub generators to populate the manifest.json files of individual widgets, etc (see #4).

In addition to ES2015 transpiling, would it be useful to allow Typescript transpiling?

Related (but not required for this to work): ArcGIS Ideas: Maintain a Typescript definition file for jimu.js

the widget test suite should only re-run the the prompts as needed (pretty much once for each describe block instead of once each test).

If the user has created a package.json file in the (stem)app root folder, either by running the app (default) generator or by hand, then we can populate the following properties in manifest.json:

• author
• copyright
• license

Per the latest JSHint, we should not be supporting these .jshintrc properties:

All of those should be replaced by: esversion. This should be set to 3,5, or 6 based on the answer to the Which JavaScript syntax version would you like to develop in?

It would be good if the grunt task supported copying custom themes over to the Web App Builder Install as 'on screen'/inPanel=false widgets are developed as part as a theme (as far as I'm aware).

Verify that the generated widgets/themes work w/ WAB v1.3, and make any changes to match the sample widget/theme code that ships w/ v1.3.

Using LiveReload is pretty easy, in conjunction with the "watch" Gruntfile task. Should we ask the user if they want to enable this?

I was able to follow instruction as described. Everything worked smoothly and I created a TEST1 widget. TEST1 widget folder has created in application's widget folder successfully. But it did not appear in Application's editor > Widget container .(Other default widgets is appearing but not new TEST1 widget)

What I am doing wrong here ?
Does new widget need to be register with ArcGIS Web App Developer module ?

Best regards

Anjitha

I was reading this excellent guide on sharing your WAB widgets and I was thinking that we could help automate the "Create a Demo App" section.

I would say rather than move the demo app under the github repo, have the grunt-gh-pages task pull the app directly from the app folder under the WAB folder structure since we know the path.

See related #56 and #69.

I was reading this excellent guide on sharing your WAB widgets and I was thinking that we could help automate some of those tasks, including scaffolding a reasonable README, to include:

• project name (from package.json)
• description: "A collection of Web AppBuilider custom widgets for..."
• instructions on:
  • how to use
  • how to contribute

v2.1 of Web AppBuilder was released recently. We should update wabVersion to reflect the latest.

Edit: v2.2 is out

keepConfigAfterMapSwitched, hasVersionManager and supportMultiInstance need to be added to the features list

I've used this tool with previous versions of WAB, but recently I get an error when specifying the path to the WAB root. I've tried all the combinations of root locations; drive letters; directory names; but nothing seems to work.

I've not looked at the source code yet to see if you are catching an error that I am not aware of but I'd like to go ahead and submit this request for a possible bug.

Can you update the generator on npm ?
thx !

Documentation says
Navigate into either stemapp or builder/apps/[appId] under your local Web AppBuilder installation
/builder/apps/[appid] does not exist, however server/apps/[appId] does

If response to the inPanel prompt is 'N', the generator currently only sets clazz.inPanel = false, but I think it also needs to set properties.inPanel: false in manifest.json as well.

Instead of using grunt sync/copy to copy ES5 files from the working folder to the WAB, we could work in ES6 and use grunt babel to transpile the code and output to the WAB folder.

This should happen after #28

Export widget scaffolding code into own node module that could be used by the builder. This way users could have a GUI form inside the builder to scaffold out new widgets.

We could build into our gruntfile, in addition to the "copier" and "transpiling" tasks, the option to do a build. See https://github.com/gbochenek/web-app-builder-build