Due to change in circumstances of the original maintainer, I was given ownership of the NPM domain js-interpreter.
My old NPM package was js-interpreter-npm (which I picked because js-interpreter was not available).
I am offering as a volunteer to maintain an NPM package for it. This is the situation right now:
js-interpreter started as a fork of js-interpreter. It deviated slightly from the original one. After our input, they changed their mind and offered js-interpreter "as is", with the bonus of it being available via the CLI. The package offers a minified version of it too, built with webpack.
js-interpreter-js. This is my original version. I do waaaaayyyy less... All I do, really, is simply sandwich js-interpreter.js with this:
So, within the function, this will be either the window, or the "exports" variable (which is what you want with node).
I didn't pre-build it as I didn't want to get in the way of js-interpreter.
Now... there are two possible ways to go about the NPM package.
WAY ONE: adding the bare minimum to make an npm package
This way would basically mean that you add the above lines to js-interpreter. We would probably have a bit of a think about THOSE lines (header/footer above) being really all we need, but generally speaking, all we do is adding a package.json file, and then add the bare minimum to make sure that node will load the module. Please note that what I DIDN'T do here is adding the possibility of loading js-interpreter as an ES6 module; doing so would require some kind of building process. We CAN do that, but it comes down to how you want to export this functionality. For myself, I am transitioning an application not to use any library that pollutes the global object. However, I would focus on the easiest, least complex and least intrusive way of doing this.
WAY TWO: I manage a repo to create all of the above
I would be happy to do that. If we go this way, I would ask you to also be marked as the NPM package's maintainer, so that if I get hit by a bus you are not left with a problem to deal with. I will also ask you to email me/notify me when there is a new version you'd like to push out in the NPM package.
I will make sure I still maintain a CLI version and an ES6 version, so that historical users of the original module are not left with something that doesn't work as intended.
Let me know which way you want to go. I am happy to be of service.
Due to change in circumstances of the original maintainer, I was given ownership of the NPM domain js-interpreter. My old NPM package was js-interpreter-npm (which I picked because js-interpreter was not available). I am offering as a volunteer to maintain an NPM package for it. This is the situation right now:
if (typeof exports === 'undefined') { scope = window } else { scope = exports var acorn = require('./acorn.js') } (function () {
...ORIGINAL JS INTERPRETER
}).call(scope)
So, within the function,
this
will be either the window, or the "exports" variable (which is what you want with node).I didn't pre-build it as I didn't want to get in the way of js-interpreter.
Now... there are two possible ways to go about the NPM package.
WAY ONE: adding the bare minimum to make an npm package This way would basically mean that you add the above lines to js-interpreter. We would probably have a bit of a think about THOSE lines (header/footer above) being really all we need, but generally speaking, all we do is adding a package.json file, and then add the bare minimum to make sure that
node
will load the module. Please note that what I DIDN'T do here is adding the possibility of loading js-interpreter as an ES6 module; doing so would require some kind of building process. We CAN do that, but it comes down to how you want to export this functionality. For myself, I am transitioning an application not to use any library that pollutes the global object. However, I would focus on the easiest, least complex and least intrusive way of doing this.WAY TWO: I manage a repo to create all of the above I would be happy to do that. If we go this way, I would ask you to also be marked as the NPM package's maintainer, so that if I get hit by a bus you are not left with a problem to deal with. I will also ask you to email me/notify me when there is a new version you'd like to push out in the NPM package. I will make sure I still maintain a CLI version and an ES6 version, so that historical users of the original module are not left with something that doesn't work as intended.
Let me know which way you want to go. I am happy to be of service.