[Experimental] Standalone Frontend Dev Server

[hydrosquall]

Motivation

This is an experiment to to make it easier for people to contribute to the frontend by reducing the amount of setup steps (no mongodb) if they're making a frontend-only change. If we like the dev experience, it might be worthwhile to extract the "client" portion of the app to its own package, which the "server" can import.

Changes

• Changed the references to process based on the simplified definition of index.html (I didn't bind the process variables to the window).
• Parcel is a "zero config" dev server that we could used instead of running a full dev server. You can find docs here. Next.js is another option that could be worth investigating.
• I am running 12.16.0 locally since I use nodenv rather than nvm, and 12.16.1 wasn't available. However, hopefully there shouldn't be significant differences.

Testing

1. Clone this branch
2. npm run parcel
3. cp .env.example .env
4. The app should work on localhost port 1234.

A live version of this app was auto-deployed to now.sh at this url:

• Branch specific URL: https://p5-js-web-editor-jhljph7vi.now.sh/
• Vanity URL works too: https://p5-js-web-editor.now.sh/

(Login and other stateful features are disabled, since I didn't supply any environment variables. However, if supplied locally, those should work too. The API_URL will probably not work out-of-the-box, since it looks like CORS is disabled with the production API.

The now Github integration is capable of automatically building branch previews every time someone opens a PR, but I manually supplied the link here since this is still early-stage.

[welcome]

🎉 Thanks for opening this pull request! Please check out our contributing guidelines if you haven't already.

[catarak]

Thanks for working on this! Question about using Parcel—is it weird to have both Webpack and Parcel in a project? Does this circumvent Webpack?

[hydrosquall]

If we like Parcel enough, it could replace webpack- I just didn’t want to prematurely remove it. In either case, both bundlers were reading from the same .babelrc, hence the changes to that file. If there are custom things that we need our webpack to do, then switching over may not make sense. If everything is covered by parcel’s defaults, we would hopefully have a smaller build related maintenance burden over time (see https://flaviocopes.com/parcel/ )

…

On Tue, Feb 25, 2020 at 4:04 PM Cassie Tarakajian ***@***.***> wrote: Thanks for working on this! Question about using Parcel—is it weird to have both Webpack and Parcel in a project? Does this circumvent Webpack? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1257?email_source=notifications&email_token=ACE2MM3Z6ZV4C24ZXPAUC7TREWBVFA5CNFSM4KUJSMYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEM5PZBA#issuecomment-591068292>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACE2MM3CE6N4GSS77RCDVK3REWBVFANCNFSM4KUJSMYA> .

[andrewn]

I agree that not having to run the API and mongodb to make front-end changes would be great!

I think we should use the same packager and config for all development environments. This will ensure making a change in the front-end-only env will be the same as the full-stack env and avoid weird bugs with the different packagers.

Perhaps a good way forward is separating the webpack dev server from the API server so that the can be run standalone? Then we could also switch to Parcel if we wanted.

[hydrosquall]

Hi @andrewn, thanks for the idea! I've filed this as an issue to take on separately from this branch: #1348

Do you have any advice about where to start on this task? I'll see if I can budget some time for it in upcoming weeks.

[catarak]

Thanks @hydrosquall!

I would be down to explore if it makes sense to move from webpack to parcel. There's really nothing fancy happening with the bundling in this app, and maybe parcel is good enough.

[hydrosquall]

I took a look another at trying with the latest Parcel 2 and the latest head of develop.

I ran into a few hurdles due to changes to both this codebase and Parcel itself, some of which seemed time effective to solve, others which do not.

1. The original index.html in this file did not work. The script type needs to be changed to module. See Browser scripts cannot have imports or exports. Use a <script type="module"> instead fregante/browser-extension-template#51 .
2. Parcel 2 did not handle importing audio files (mp3) by default. This was fixable by following How to correctly load local assets like audio files parcel-bundler/parcel#1911 , I chose to create a .parcelrc instead of doing the url: prefix method to avoid breaking the existing code.
3. Parcel 2 does not handle resourceQuery, and there are no plans to do so. ( see Is there a Parcel equivalent to Webpack's resourceQuery? parcel-bundler/parcel#2186 , Suggestion: myurl?static should tell parcel to copy the file as-is parcel-bundler/parcel#1084 ). This is an issue because the P5 editor needs this to load SVG files in 3 different ways:
   a. As raw text files, to inline (?byContent), as part of the replace feature
   b. As URL paths, to inject into stylesheets (?byUrl) (added as part of Make SVG icons web accessible #1420 )
   c. As React components (with the SVGR Loader) (Seemed to mostly change as part of b too).

p5.js-web-editor/webpack/config.prod.js

Lines 119 to 140 in f373938

	test: /\.svg$/,
	oneOf: [
	{
	resourceQuery: /byContent/,
	use: 'raw-loader'
	},
	{
	resourceQuery: /byUrl/,
	use: 'file-loader'
	},
	{
	use: {
	loader: '@svgr/webpack',
	options: {
	svgoConfig: {
	plugins: {
	removeViewBox: false
	}
	}
	}
	}
	}

I look at the code that actually reads these SVGs. It didn't seem worthwhile to rewrite this code such that all SVGs are loaded in 1 way, since there seemed to be legitimate reasons to be loading icons in 3 different ways in the editor for now.

I didn't have confidence that this would be the end of Parcel configuration issues (inability to load relative URLs looked problematic too parcel-bundler/parcel#206 ), so I think may be best to retire the idea of using Parcel 2 to bundle this project, given that the current webpack config has a few customized asset loaders.

It might be more practical to get the standard webpack dev server working instead, so I'm going to try that in a separate PR.

References

• Proof-of-concept branch with Parcel 2 (build fails because it's not sure how to handle SVGs with resourceQuery strings, but it solves 1 and 2): https://github.com/hydrosquall/p5.js-web-editor/tree/cameron.yick/experiment/parcel-frontend-only

[hydrosquall]

Closing this PR as it will be replaced by #1999 .