#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 3 years ago by
| Component: | General → BuildSystem |
|---|---|
| Milestone: | tbd → 1.11.3 |
| Priority: | undecided → high |
comment:2 Changed 3 years ago by
| Milestone: | 1.11.3 → 1.12 |
|---|
comment:3 Changed 3 years ago by
| Owner: | set to Michael Van Sickle <mvansickle@…> |
|---|---|
| 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.