NPM support about mathcell

[paulmasson]

@Ryunaq glad you like the project! And of course, every project can use improvement.

I'm a proponent of vanilla JavaScript, so I don't have any plans to support build systems of any kind. I can understand why someone would use a build system to extract a tiny part of some very large project, but my entire library is less than 100K unminified. It's intended to be loaded once in a web page so there's not much overhead at all. And I just don't like the idea of a separate build step for JavaScript when it runs immediately on refresh.

Can you give me a use case scenario where a module would significantly increase performance? What are you looking to achieve with this library?

[shiranaiyo]

Yeah I do agree that there wouldn't be a significant increase in performance; I meant to say that some (most?) workflows are already using npm so it's easier for developers to plug and play more easily rather than adding some script tags. But again it's kind of preference, I am some sort of a proponent of npm JavaScript. If I were to make a pull request so that this becomes an NPM module would you merge it?

I am only looking to use it on my personal website (wip) to post random math stuff that I think or read about, this is really almost exactly what I wanted :) (The only usecase that I am missing is for inserting dom elements instead of graphics, e.g. a cayley table, but I'll probably do it anyways in a hacky way).

[paulmasson]

What exactly would be involved in the PR? How many files would be added/changed? I don't use NPM much, but I have seen vanilla JS libraries packaged for NPM without touching the library itself. Is that an option you might consider?

FYI you should always use a numbered version of this library, since I'm likely to break things moving forward.

While I already have a matrix output, a table output could be useful. Want to open a separate issue for that and describe what you'd need in a bit more detail? Thanks!

[shiranaiyo]

I'm not an expert on npm modules but I think that the packaging must touch the js library in some form necessarily, though this can be minimized. What would change:
Adding:

• package.json
  Modifications:
• Adding a bunch of exports. in the exported functions. (I haven't checked this library in detail but it wouldn't be a lot). For example, the colormaps module would have to be exported so that the functions can use it, and also a export for the main function which is in the core.
• If this were to become an NPM module, I think it would make sense to use other npm modules then. This is not mandatory but I'd like to use ESLint, if you don't know it, it basically enforces some syntax on all the files so it's easier to read while avoiding possible mistakes.

Again, this is up to you though, if you don't want these changes I can just fork it and continue my own development. I'd still like to publish it in npm though, ofc crediting you with the initial codebase.

I am unsure of the table requirements, maybe it could be a svg or a real dom table, I'd have to think more about it to open the PR but I'll be on it.

[paulmasson]

@Ryunaq that's more changes than I want to make right now. Feel free to modify a fork and publish it. Thanks!