Open codingmatty opened 8 years ago
This is a good feature suggestion and something I would love to add. Also, being able to run two different versions of the same package sounds like a good feature as well, as long as the code written to support this can be simple.
If anyone want to try to implement it (my time is limited right now), https://github.com/VictorBjelkholm/trymodule/blob/master/index.js#L30 would be the part where version
is necessary to add (npmi docs here: https://github.com/maxleiko/npmi#optionsversion ). The multiple version packages thing I see as an extra addition that would simply resolve lodash@0.1.0 to be lodash
in global context by default, but if the user provides lodash@0.1.0
and lodash@0.2.0
to be lodash_v0_1_0
and lodash_v0_2_0
in the global context (which is kind of ugly, if someone has a better idea of variable naming, please step forward :) )
What if the user could set an alias for a module ?
Like trymodule "lodash@0.1.0 as l1" "lodash@0.2.0 as l2"
.
Or shorter like trymodule lodash@0.1.0=l1 lodash@0.2.0=l2
But it's only a suggestion maybe too much work involved here ;).
@jlebras I've opened a issue for that here: https://github.com/VictorBjelkholm/trymodule/issues/17
Once #19 is merged this should be pretty straightforward 😃
I'm thinking how we can actually implement this. I did some quick hacking today, trying to just setting the version when calling npmi
but it's not enough since npm has no feature for handling multiple versions of the same package.
var version = 'latest'
if (moduleName.indexOf('@')) {
version = moduleName.split('@')[1]
moduleName = moduleName.split('@')[0]
}
npmi({name: moduleName, path: install_path, version}, (err, result) => {
So even with the change above, I'm not sure how to do this... If anyone have any ideas, please speak up! :)
Say you want to load lodash@1.0.0
and lodash@2.0.0
.
We'll say the command looks like trymodule lodash@1.0.0=lodash1 lodash@2.0.0=lodash2
Something that flows sequentially like this could work.
lodash@1.0.0
require('lodash')
and assign the result to the REPL scope as lodash1
lodash@2.0.0
require('lodash')
and assign the result to the REPL scope as lodash2
In doing this, we must be careful to work around require's module caching.
Currently, this tool always uses
@latest
, but it'd be nice to be able to specify a specific version to try out. It helps when you are trying to identify problems after upgrading. I don't know if you'd want to allow 2 versions in the same session, that might be overkill.