Closed guybedford closed 9 years ago
yeah!
+1! The idea here that not all base things should be supported, but some things could be jspm specific, only allowed in the jspm section. This could apply to other things too.
This has been enabled with https://github.com/jspm/jspm-cli/commit/32670f70d65cc40baa464dd67d6a26023980cc26 and https://github.com/jspm/npm/commit/b1cf19b40ae0ab1ec98cfd02899063591d240bde.
It just needs final testing for release.
What's the simplest way to test unreleased versions of jspm?
@theefer I've been meaning to get documentation together on this, there is an issue at https://github.com/jspm/jspm-cli/issues/323#issue-52243599, aiming to work on the docs as soon as I've got this release out.
Tested and working.
I was wondering how this behaves in transitive npm dependencies.
For example, jspm app J depends on npm lib N1 which depends on npm lib N2. J -> N1 -> N2. Package N2 has jspm.directories.lib
set to "src". Being a simple npm package, N1 refers to N2 modules as "N2/src/foo.js". Will this break when running J within jspm since it may only know "N2/foo.js"? Or does jspm.directories.lib
only apply when modules of N2 are imported from a jspm package directly (J)? I haven't tested it, but it worries me a bit.
@neothemachine This is a good question. I believe it breaks, because JSPM will move the directory listed in directories.lib
to the root of the installed JSPM package. So, if N2 normally has the following file structure as an NPM package
node_modules/
N2/
src/
foo.js
then the JSPM version of the package will have the structure
jspm_packages/
npm/
N2/
foo.js
so it seems that importing N2/src/foo
would fail.
If a
directories.lib
is provided in ajspm
property in the package.json or in an override, we should still support it. Just the base-leveldirectories.lib
should be ignored.