search

stack-tools-js / stack-tools

Utilites for printing and parsing errors and their stacks
5 stars 1 forks source link

Monorepo #4

Closed conartist6 closed 3 years ago

conartist6 commented 3 years ago

I'm thinking of changing the packages around from how they would be if I published now. Right now I only have one package, and I'm absolutely sure that I'm going to need more than one. Even the one I have already is better described as two packages. I have the environment-agnostic implementation which I hope will be used very widely, as it has a wide range of possible uses. Since this that part will have the highest usage and visibility, it makes good sense not to introduce anything unnecessary to it that might confuse the point about what the package is for, who should be using it, and how it should be used. Also from a technical perspective we shouldn't consume resources (storage, complexity) with v8 code that most users of the base package will not actually want or use.

The obvious choice then is to simply covert this to a monorepo. The implementations are already essentially separate units, I just need move v8 into a packages folder and add a package.json and a README.md.

This will also make it easier to publish other packages that are closely related to the core, e.g. html printing, react rendering, and chalk rendering. Having all these packages in one repo is great, because a syntax addition in the core (which will happen as often as the language introduces new syntaxes in its errors) will require changing the related packages, particularly those for printing.

conartist6 commented 3 years ago

Here are packages I've currently planned:

stack-tools
@stack-tools/v8
@stack-tools/v8-print-chalk
@stack-tools/v8-print-html
@stack-tools/v8-render-react
conartist6 commented 3 years ago

If we gain more environment-specific implementations they obviously would fit nicely into this system, and it might be possible eventually to include an @stack-tools/ployglot package which would be noticeably heavier but which supported the major browsers. I think such a package would be most correct if it printed errors in the browser's own format, though it would be possible to try to render an error with different formatting. It isn't yet clear if there will be demand for that use case, and I haven't studied other environment's errors yet to see how well my data structure applies to the other syntaxes.

conartist6 commented 3 years ago

This work is now complete.