-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use folders instead of separate npm packages #70
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
d534592
to
96bacf9
Compare
adamziel
added a commit
that referenced
this pull request
Mar 10, 2023
This PR splits the repository into five node packages that are also yarn workspaces: - php-cli - php-wasm - typescript-reference-doc-generator - wordpress-playground - wordpress-plugin-ide This effectively undoes [Use folders instead of separate npm packages](#70), so you may ask "why bother?" With this PR: * The build process is straightforward. There's no `gulp` and there's no mountain of custom logic in `esbuild.js`. Files are moved around the repo using a simple `copy` plugin or an `import` statement. There's no custom cache busting logic – it's handled by the build tools instead * `php-wasm` is now reusable and can be published in npm. This means it can be easily reused outside of WordPress Playground. * Each package has its own build process that caters to its specific needs. For example, `php-cli` outputs a node.js script. Web workers can now be bundled as `iife` (which is the only way to use them in firefox) while other assets are es modules. * There are less tasks in general. For example, TypeScript types are handled by rollup in a few packages. At the same time, none of the [original downsides of using packages ](#70) are present: * There's no global build pipeline. Every package outputs a complete build artifact that can be directly imported in case of libs, or used in the browser in case of the Playground website. * Yarn workspaces ensure the tasks are executed in the correct order * tsconfig.json and package.json can mostly be copied, there's no `api-documenter.json` at all.
adamziel
added a commit
that referenced
this pull request
Mar 10, 2023
This PR splits the repository into five node packages that are also yarn workspaces: - php-cli - php-wasm - typescript-reference-doc-generator - wordpress-playground - wordpress-plugin-ide This effectively undoes [Use folders instead of separate npm packages](#70), so you may ask "why bother?" With this PR: * The build process is straightforward. There's no `gulp` and there's no mountain of custom logic in `esbuild.js`. Files are moved around the repo using a simple `copy` plugin or an `import` statement. There's no custom cache busting logic – it's handled by the build tools instead * `php-wasm` is now reusable and can be published in npm. This means it can be easily reused outside of WordPress Playground. * Each package has its own build process that caters to its specific needs. For example, `php-cli` outputs a node.js script. Web workers can now be bundled as `iife` (which is the only way to use them in firefox) while other assets are es modules. * There are less tasks in general. For example, TypeScript types are handled by rollup in a few packages. At the same time, none of the [original downsides of using packages ](#70) are present: * There's no global build pipeline. Every package outputs a complete build artifact that can be directly imported in case of libs, or used in the browser in case of the Playground website. * Yarn workspaces ensure the tasks are executed in the correct order * tsconfig.json and package.json can mostly be copied, there's no `api-documenter.json` at all.
adamziel
added a commit
that referenced
this pull request
Mar 16, 2023
## Description Sets up the correct build pipeline for all parts of Playground and PHP.wasm. This enables a public release of the [Playground API](#149) npm package! I've been [struggling](#146) with [this](#70) for [a while](#150) and couldn't understand what's so hard. NX made it apparent – look at this dependency graph! <img width="1291" alt="CleanShot 2023-03-16 at 23 16 26@2x" src="https://user-images.githubusercontent.com/205419/225764795-7fa8e972-09f8-41ef-aac2-1c96bd100ea0.png"> No wonder it's been almost impossible to set everything up by hand! ## Usage Start with `yarn install` ### Shortcuts To start a copy of `wasm.wordpress.net` locally, run `yarn run dev`. To build it, run `yarn run build`. ### Fully qualified commands In reality, these `yarn run` commands are just triggering the underlying project's nx `dev` and `build` commands: ```bash nx dev playground-website nx build playground-website ``` Here's a few more interesting commands: ```bash # Build and run PHP.wasm CLI nx start php-wasm-cli # Build latest WordPress releases nx recompile-wordpress:all playground-remote # Recompile PHP 5.6 - 8.2 releases to .wasm for web nx recompile-php:all php-wasm-web # Recompile PHP 5.6 - 8.2 releases to .wasm for node nx recompile-php:all php-wasm-node # Builds markdown files for readthedocs site nx build docs-site # Builds the Playground Client npm package nx build playground-client ``` ## NX is the tool Playground needed from the outset It's ridiculous how many problems this solves: * The build pipeline is explicitly defined and easy to modify * Tasks only run once their dependencies are ready * The dev mode works and is fast * The build works and is fast * We get CI checks to confirm the entire build process still works (which solves #150) * Cross-package TypeScript just works * There are linters and formatters (which solves #14) * Documentation is correctly generated from the latest built artifacts * There are nice generators for bootstraping new packages and moving the existing ones around * There are checks to ensure the private `php-wasm-common` package is not imported by anything else than `php-wasm-web` and `php-wasm-node` ## Next steps * Add Lerna to harness package publishing * Additional developer documentation for the nx-based flow Related to #148 and #147
Pookie717
added a commit
to Pookie717/wordpress-playground
that referenced
this pull request
Oct 1, 2023
This PR splits the repository into five node packages that are also yarn workspaces: - php-cli - php-wasm - typescript-reference-doc-generator - wordpress-playground - wordpress-plugin-ide This effectively undoes [Use folders instead of separate npm packages](WordPress/wordpress-playground#70), so you may ask "why bother?" With this PR: * The build process is straightforward. There's no `gulp` and there's no mountain of custom logic in `esbuild.js`. Files are moved around the repo using a simple `copy` plugin or an `import` statement. There's no custom cache busting logic – it's handled by the build tools instead * `php-wasm` is now reusable and can be published in npm. This means it can be easily reused outside of WordPress Playground. * Each package has its own build process that caters to its specific needs. For example, `php-cli` outputs a node.js script. Web workers can now be bundled as `iife` (which is the only way to use them in firefox) while other assets are es modules. * There are less tasks in general. For example, TypeScript types are handled by rollup in a few packages. At the same time, none of the [original downsides of using packages ](WordPress/wordpress-playground#70) are present: * There's no global build pipeline. Every package outputs a complete build artifact that can be directly imported in case of libs, or used in the browser in case of the Playground website. * Yarn workspaces ensure the tasks are executed in the correct order * tsconfig.json and package.json can mostly be copied, there's no `api-documenter.json` at all.
Pookie717
added a commit
to Pookie717/wordpress-playground
that referenced
this pull request
Oct 1, 2023
This PR splits the repository into five node packages that are also yarn workspaces: - php-cli - php-wasm - typescript-reference-doc-generator - wordpress-playground - wordpress-plugin-ide This effectively undoes [Use folders instead of separate npm packages](WordPress/wordpress-playground#70), so you may ask "why bother?" With this PR: * The build process is straightforward. There's no `gulp` and there's no mountain of custom logic in `esbuild.js`. Files are moved around the repo using a simple `copy` plugin or an `import` statement. There's no custom cache busting logic – it's handled by the build tools instead * `php-wasm` is now reusable and can be published in npm. This means it can be easily reused outside of WordPress Playground. * Each package has its own build process that caters to its specific needs. For example, `php-cli` outputs a node.js script. Web workers can now be bundled as `iife` (which is the only way to use them in firefox) while other assets are es modules. * There are less tasks in general. For example, TypeScript types are handled by rollup in a few packages. At the same time, none of the [original downsides of using packages ](WordPress/wordpress-playground#70) are present: * There's no global build pipeline. Every package outputs a complete build artifact that can be directly imported in case of libs, or used in the browser in case of the Playground website. * Yarn workspaces ensure the tasks are executed in the correct order * tsconfig.json and package.json can mostly be copied, there's no `api-documenter.json` at all.
Pookie717
added a commit
to Pookie717/wordpress-playground
that referenced
this pull request
Oct 1, 2023
## Description Sets up the correct build pipeline for all parts of Playground and PHP.wasm. This enables a public release of the [Playground API](WordPress/wordpress-playground#149) npm package! I've been [struggling](WordPress/wordpress-playground#146) with [this](WordPress/wordpress-playground#70) for [a while](WordPress/wordpress-playground#150) and couldn't understand what's so hard. NX made it apparent – look at this dependency graph! <img width="1291" alt="CleanShot 2023-03-16 at 23 16 26@2x" src="https://user-images.githubusercontent.com/205419/225764795-7fa8e972-09f8-41ef-aac2-1c96bd100ea0.png"> No wonder it's been almost impossible to set everything up by hand! ## Usage Start with `yarn install` ### Shortcuts To start a copy of `wasm.wordpress.net` locally, run `yarn run dev`. To build it, run `yarn run build`. ### Fully qualified commands In reality, these `yarn run` commands are just triggering the underlying project's nx `dev` and `build` commands: ```bash nx dev playground-website nx build playground-website ``` Here's a few more interesting commands: ```bash # Build and run PHP.wasm CLI nx start php-wasm-cli # Build latest WordPress releases nx recompile-wordpress:all playground-remote # Recompile PHP 5.6 - 8.2 releases to .wasm for web nx recompile-php:all php-wasm-web # Recompile PHP 5.6 - 8.2 releases to .wasm for node nx recompile-php:all php-wasm-node # Builds markdown files for readthedocs site nx build docs-site # Builds the Playground Client npm package nx build playground-client ``` ## NX is the tool Playground needed from the outset It's ridiculous how many problems this solves: * The build pipeline is explicitly defined and easy to modify * Tasks only run once their dependencies are ready * The dev mode works and is fast * The build works and is fast * We get CI checks to confirm the entire build process still works (which solves #150) * Cross-package TypeScript just works * There are linters and formatters (which solves #14) * Documentation is correctly generated from the latest built artifacts * There are nice generators for bootstraping new packages and moving the existing ones around * There are checks to ensure the private `php-wasm-common` package is not imported by anything else than `php-wasm-web` and `php-wasm-node` ## Next steps * Add Lerna to harness package publishing * Additional developer documentation for the nx-based flow Related to WordPress/wordpress-playground#148 and WordPress/wordpress-playground#147
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR greatly simplifies the repository setup by getting rid of the separate
package.json
files as they made the setup unnecessarily complex.Before this PR
tsconfig.json
setups meant we needed to rebuild types in a particular order to even get the dev environment to work.tsconfig.json
made it extra hard. Substituting env variables caused conflicts.package.json
,tsconfig.json
,api-documenter.json
, adjusting all the build pipelines, ensuring the build steps are triggered in the correct order etc.After this PR
tsconfig.json
files in the repo root and that's it. One is for the main-thread code and the other is for the worker code.