Opened 6 years ago

Closed 3 years ago

Last modified 3 years ago

#17193 closed defect (fixed)

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

Reported by: simpo Owned by: dylan
Priority: high Milestone: 1.11
Component: BuildSystem Version: 1.9.0
Keywords: Cc:
Blocked By: Blocking:

Description

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?

Attachments (1)

hasUndefined.patch (1.4 KB) - added by simpo 6 years ago.
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.

Download all attachments as: .zip

Change History (7)

Changed 6 years ago by simpo

Attachment: hasUndefined.patch added

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.

comment:1 Changed 6 years ago by Colin Snover

Owner: set to simpo
Status: newpending

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.

comment:2 Changed 6 years ago by simpo

Status: pendingnew

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.

Last edited 6 years ago by simpo (previous) (diff)

comment:3 Changed 3 years ago by dylan

Milestone: tbd1.11
Owner: changed from simpo to dylan
Status: newassigned
Summary: Default values for staticHasFeatures in builder[patch][cla] Default values for staticHasFeatures in builder

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

comment:4 Changed 3 years ago by dylan

Priority: undecidedhigh

comment:5 Changed 3 years ago by Dylan Schiemann <dylan@…>

Resolution: fixed
Status: assignedclosed

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? 

comment:6 Changed 3 years ago by 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!

Note: See TracTickets for help on using tickets.