Use prepare script to generate lib on install from git

[cinderblock]

Using prepare step to build enables using a github version of this package as a dependency in other projects directly.
https://docs.npmjs.com/misc/scripts#prepublish-and-prepare

Specifically, one should be able to run npm install https://github.com/josdejong/mathjs and immediately start using the package. As it stands, one needs to do a few extra steps to use:

cd node_modules/mathjs
npm install
npm run build

However, if the repo is configured "correctly" the manual steps after the install are completely superfluous. Npm automatically installs devDependencies needed for build too! Try installing my fork from git to see that it "just works™": npm i https://github.com/cinderblock/mathjs.

Note: prepublishOnly is run after prepare script so this change should have no other effect.

[harrysarson]

Thanks for this pull request! I like the idea but I do not like how messy our npm scripts are getting. (This is far from a criticism of this pull request, the number of scripts we have has been too many for a while now but this pull request has simply highlighted that fact.)

I think a better solution to this problem would be to find a way to run a local copy of mathjs without needing to transpile the build files. That should be possible in node 13 (https://nodejs.org/api/esm.html) but we may have to make some changes to mathjs to make it work.

I would be much more keen on a patch that got native esm working in node. Anyway, thanks for this patch and sorry for my brain dump. What do you think @josdejong?

[cinderblock]

I'm with you on the messiness of the package.json scripts. I was tempted to try some basic cleanup but didn't want to open that can of worms.

Personally, I've started using a whole extra folder on my repositories to store the actual scripts that I use. Much more control. Often better cross platform support too.

In any case, I still think it should be trivial to install from git directly. The naive way of doing this would be to include the compiled sources in the git repo, which it looks like this package used to do. This problem got exacerbated by the poor documentation and a whole lot of sub-par community partial solutions.

[josdejong]

Thanks Cameron. Can you explain a bit more about your use case? Why would you want "to use a github version of this package as a dependency in other projects directly."?

In the past we where forced to commit the generated bundles in the repository too, which is a disaster. This was needed to allow support for bower which simply publishes repositories (source code) as library. I do like a clear separation between source code and a generated library bundle.

[cinderblock]

Specifically, I wanted to try the #1741 PR for myself but could not since it is not published to NPM.

Had it had the changes I'm suggesting, I would have been able to simply run:
npm i m93a/mathjs#patch-eigens

See "npm install <githubname>/<githubrepo>[#<commit-ish>]:" at https://docs.npmjs.com/cli/install

Instead, I had to merge my changes with their changes so that I could try their implementation before it gets accepted by your repository and published to npm.

Basically, it's the official way to enable installing "compiled" version of the code to node_modules from a git repository directly, even when the git repo does the correct thing of not including the "compiled" version of files. It should have no change for a standard npm publish but fixes problems for people that want to depend on any bleeding edge.

If you'd like to read more, there is a huge issue on the topic: npm/npm#3055 (comment)

[josdejong]

That's indeed very convenient. Are there any downsides to using prepare that you guys know of?

[harrysarson]

I have a down side I think.

The current workflow:

1. Clone mathjs.
2. run mathjs in the node repl.
3. Realise it doesn't work.
4. Google/read the package json/read our docs.
5. run npm build
6. run mathjs in the node repl.
7. make a change to the source.
8. run npm build again
9. test the change in the repl. Observe the change.

I worry that with this change we instead have:

1. Clone mathjs.
2. run mathjs in the node repl.
3. It works!
4. make a change to the source.
5. test the change in the repl. Mathjs runs exactly as before. No matter what you do you cannot see the changes you made in the repl.
6. Fustration.

[cinderblock]

@harrysarson Have you tested this? I don't think it will "work" after just running "Clone". It does not run the build unless npm i has been run.

However, thanks for bringing this up. Contrary to my previous statement, there is one small difference I'm seeing: running npm i inside of a cloned repo will also run the build script. Frankly however, I don't see that as a problem, and actually feel like it's more of a feature.

Previous workflow

1. git clone https://github.com/josdejong/mathjs
2. cd mathjs
3. npm i
4. npm run build
5. do whatever dev/testing/repl you like

New workflow

1. git clone https://github.com/josdejong/mathjs
2. cd mathjs
3. npm i
4. do whatever dev/testing/repl you like

The only "downside" I'm seeing is that if you ever run npm i (without any arguments only) it runs the build script which might not be necessary. But npm i should not be necessary either...

[josdejong]

Thanks Harry I understand your point. I think though that it mostly moves the "WTF" point where you probably have to check the docs, but I don't think it's really a regression. And on the contrary it has a better out of the box experience I think.

Only think I can come up with is that when you've committed a feature branch that you're working on which has a broken build, and you try to check it out, stuff is broken (which makes sense). I run npm i locally quite regularly, after updating a dependency. I think though it's acceptable to have this run a bit slower because it's doing a build too.

@harrysarson and @cinderblock shall we simply give it a try and see how it work out?

[harrysarson]

Lets merge!

I have come to think the issue I have is tangential to this. I will gro away and so if I can come up with a patch to help us avoid the need for build scripts on recent nodejs releases. If it is possible then that is the best path to making contribution straightforward.

In the meantime this patch is a positive step towards it being easier to contribute to mathjs.

[josdejong]

👍 merging now

[josdejong]

I've created a script test:all to remove a bit of duplication, see 9272395.

[josdejong]

Published now in v6.6.2, sorry for the delay