#18868 closed defect (fixed)
Hardcoded './util/…' paths in dojo-util break when installed via npm
Reported by: | tupton | Owned by: | |
---|---|---|---|
Priority: | high | Milestone: | 1.12 |
Component: | BuildSystem | Version: | 1.11.2 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
If one installs dojo-util
via npm
, it gets installed to a directory called …/node_modules/dojo-util
. Because there are numerous scripts within dojo util that hardcode util
as part of the path, these scripts break.
There should be a way to make these paths relative without having to hardcode util
in there, or at the very least there should be a mechanism to provide the name of the directory in which dojo-util
is located.
Right now, the "workaround" is to install dojo-util
via bower
, which lets you specify custom directory names. This isn't ideal, as npm
is more active, better-supported, and the preferred way to install front-end dependencies, and we'd like to standardize on it. dojo et al. are the last remaining packages of ours that cannot be installed via npm
. npm
does indeed support custom directory installations, but it's unclear whether or not that's a happy accident. In any case, it doesn't play well with npm-shrinkwrap
which is vital to creating reproducible builds and accurate development, testing, and staging environments.
(Apologies if this issue has come up before or if there's another ticket around this, but I searched and couldn't find anything.)
Change History (9)
comment:1 Changed 5 years ago by
Component: | General → BuildSystem |
---|---|
Milestone: | tbd → 1.11.3 |
Priority: | undecided → high |
comment:2 Changed 4 years ago by
Milestone: | 1.11.3 → 1.12 |
---|
comment:3 Changed 4 years ago by
Owner: | set to Michael Van Sickle <[email protected]…> |
---|---|
Resolution: | → fixed |
Status: | new → closed |
In 810db61/dojo:
Yes, npm's insistence that you cannot alias the name of a module has been very frustrating for us with this and with dstore ( https://github.com/SitePen/dgrid/blob/master/doc/usage/npm.md ).
That said, I think in this case, this is something we can fix. If you'd like to work on a pull request, let me know, otherwise we'll aim to get this done in the next month or two.