Pegjs: Yarn Workspace

[futagoza]

After 0.11 (but before 0.12) I'm planning to reorganise the repository into a monorepo using Yarn workspaces and re-implement the pegjs module into independent modules that mostly live in @pegjs (with the official grammars in @peg).

Below is a list of modules that I currently plan to implement, but this might change before 0.12 is released.

Modules

• @pegjs/lib wrappers for the latest features of ECMAScript used by PEG.js
• @pegjs/util common code shared across the PEG.js packages
• @pegjs/harness a set of modules to simplify testing PEG.js and similar tools
• @pegjs/design library of functions and classes to help build ASTs and specs
• @pegjs/config manage and optionally verify options used by PEG.js
• @pegjs/language ast classes, opcodes, basic code writer and error classes
• @pegjs/parser the PEG.js grammar parser
• @pegjs/bytecode methods to work with the PEG.js bytecode
• @pegjs/runtime the runtime for generated parser's
• @pegjs/linter various pass's that can be used to check a grammar source or ast
• @pegjs/javascript a ES5/ES20x code generator for the PEG.js compiler
• @pegjs/compiler runs the linter and more pass's, before generating the parser
• @pegjs/core the main api library
• @pegjs/cli https://en.wikipedia.org/wiki/Command-line_interface
• @pegjs/repl https://en.wikipedia.org/wiki/Read–eval–print_loop
• @pegjs/run #522

Interfaces

• pegjs A standalone release for Node.js that points to the latest minor release's (e.g. 0.12.x)
• @pegjs/browser the browser release (currently a bower package)
• @pegjs/x A no plugins, single pass, minimal options and speed-only variant (inspired by #348)
• @pegjs/e adds experimental features to both the grammar and API (testbed for public use)

[StoneCypher]

does this mean that downstream users have to switch to yarn?

[StoneCypher]

Please don't move one of the internet's major tools into a niche experimental build strategy on a different build infrastructure managed by a company that many of us don't trust

Yarn is dying and workspaces are poorly designed

Most node users will not switch to yarn for you

https://stackoverflow.com/questions/46947557/do-yarn-workspaces-work-with-npm-too

[StoneCypher]

I would be happy to help you build a normal modern build structure that doesn't require everyone to switch tooling to Facebook's stuff, if you want that help

You can use rollup and babel (or any number of other setups) to make plain ES5 from that with no overhead. Doesn't require a full new infrastructure.

In the process I could add some other really important stuff, like typescript and flowtype support, es6 module support, and other stuff

[futagoza]

@StoneCypher Hold your horse's mate 😆 Yarn is just an alternative to NPM, so the downstream users can have either NPM, Yarn or the many others that are popping up, without worrying about workspaces because this is a feature that will only be used by the root package.json ("private": true) within this repo, all the sub-modules mentioned above will be independent modules published on NPM that separate different parts of the code and just make life easier for me or anyone developing and/or hacking on the PEG.js compiler.

Also, Rollup and Babel both tackle different problems from each other and Yarn:

• Yarn is a package manager with workspace support
• Rollup is a bundler like Browserify, only it removes dead-end code
• Babel is an ES2018+ to ES* transpiler

[StoneCypher]

as long as this doesn't force me into yarn

[StoneCypher]

So, you forced me into yarn. Several of the PRs from other people that you have refused to merge have tried to take it back out, because yarn is dying, and a low quality tool that doesn't work well on Windows.

yarn offers no value.

yarn offers a significant barrier - many people won't install a new package manager to help you (I refused several times before breaking down,) and many other people aren't allowed to because of work policy.

The behavior of npm has changed. yarn has not kept up. yarn behavior now significantly differs from community expectations.

The monorepo also does not provide value, creates a complex extra build step, defies norms, and confuses potential contributors.

All of this was much more work than the feature work you aren't doing.

I think you may have gotten confused about the nature of my objection.

This is wasted work that makes it harder for people to join (not that it matters, since as of last month you made it literally impossible for anyone to contribute to what you now call "your hobby project," and expect to wholesale replace.)

This slows down the build, and loses the new tooling that npm has that yarn does not.

Yarn was dying in 2018. It's 2020. Yarn's basically dead now.

I haven't had it installed on any of my computers for years. I had to reinstall it for you.

Please let this be a normal project with normal healthy development patterns again, instead of your private codebase using fringe tools that goes three years without a release despite extremely important codebase fixes in the repo.

Yes, I see you trying to explain what yarn does, but everyone knows what yarn does.

You created exactly the new infrastructure I asked you not to create two years ago, and you're currently throwing it away for exactly the reasons I said it wouldn't work.