[patch][cla] Default values for staticHasFeatures in builder

[simpo]

The builder appears to assume a standard set of staticHasFeatures features that cannot be reset to not defined. For example it assumes that both host-browser & dom are true.

This is a problem if you want these values to be unset. You can apply an override and set them to your own choice of true or false. However, you cannot set them to unset so that builder does not resolve them. Hece, if you want the builder to leave has("host-browser") and has("dom") intact without inserting any value this is not possible.

It is not possible to make a build that will work in both Node and the Browser (as far as I can tell). I hit this problem when trying to create a build that can be used in the browser and a webworker (see: ​https://bugs.dojotoolkit.org/ticket/11750). The builder inserts values where you may want those values to be calculated in the live environment.

I've done a bit of testing and figured that you can set these values to undefined and this partially fixes the issue. Using undefined fixes any issues with the has plugin, eg:

dojo/has!dom?<some module>

The above remains intact when undefined is applied to dom (via staticHasFeatures). However, the builder then resolves all has("dom") statements to undefined instead of leaving them to be resolved in the live environment.

It would be good if there was some way of removing these defaults and instructing the builder to leave the statement intact.

I've had a dig around in the builder code and could not find any obvious way to override this. Sorry, if this is not a bug and I've just missed the setting?

[simpo]

Possible patch, this will maintain has statements in the build when a value is set to undefined in staticHasFeatures. This means that hasFixup.js and plugins/has.js work consistently in the builder.

[Colin Snover]

Why would you make a build that works on a server-side environment? There is no need to optimise code there so I’m not sure how these particular default values are a problem.

For what it’s worth you can currently require(["build/buildControlDefault"], ...) and then delete from the default flags, though this is a potentially crappy way to have to do it.

[simpo]

I take your point that you wouldn't normally want a build for the server. It was a bad example.

The issue I was trying to fix was getting a build to work in both Webworker and the normal browser window. This is not officially supported for Dojo at the moment but it can be achieved with a few tweaks. However, the tweaked version is totally screwed when built (due to defaults). You can have two local Dojo copies, one for browser and one for worker but much better to have one.

Since, it isn't even supported by Dojo then I'm not even sure if it should be registered here as an issue. Apologies if I'm wasting anyone's time on this one.

I figured that there was an inconsistency in how staticHasFeatures was used by the builder when dealing with has("<SOME FEATURE>") v dojo/has!<SOME FEATURE>?<some module>. Hence, I thought it might be worth posting as an issue.

Also, if Dojo decided to build in webworker support then it might need changing in that instance.

Anyway, like I said, apologies if this is a time waster.

[dylan]

Given the increasing popularity of things like Electron, I can see the use case for this as more important than it was previously.

[Dylan Schiemann <dylan@…>]

In 95a071b8e1cc3ad7fb06bbd158627e05ccbb95ac/util:

Error: Processor CommitTicketReference failed

Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

[dylan]

Not going to backport this as it does introduce a slight change. Documenting the change in the release notes for 1.11.

Thanks again @simpo for the patch!