You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
note that using the browserify API, './shims/d3.js' will be resolved against the current working directory.
and separately:
configDir - An absolute path to resolve relative paths against. If you're using package.json, this will automatically be filled in for you with the directory containing package.json. If you're using a .js file for configuration, set this to __dirname.
In my opinion it would make sense to always resolve against package.json (except of course when file-relative operation is enabled through {relative: "replacement"}). Especially it would allow one to use aliasify for package-relative paths in package.json like this:
.. where jquery.custom is in the same directory as the package.json file. Then it would still "just work" even when somebody else depends on mypkg.
I understand that you might not want to break backwards compatibility with existing implementations that have implemented paths based on how they work now; it would require a major release. But perhaps you could introduce a config option to enable the new behaviour until then?
There are plenty of npm packages available to figure out the associated package.json file location. For example this looks decent: https://www.npmjs.com/package/pkg-up
The text was updated successfully, but these errors were encountered:
and separately:
In my opinion it would make sense to always resolve against package.json (except of course when file-relative operation is enabled through
{relative: "replacement"}
). Especially it would allow one to use aliasify for package-relative paths in package.json like this:.. where jquery.custom is in the same directory as the package.json file. Then it would still "just work" even when somebody else depends on
mypkg
.I understand that you might not want to break backwards compatibility with existing implementations that have implemented paths based on how they work now; it would require a major release. But perhaps you could introduce a config option to enable the new behaviour until then?
There are plenty of npm packages available to figure out the associated package.json file location. For example this looks decent: https://www.npmjs.com/package/pkg-up
The text was updated successfully, but these errors were encountered: