Removing in-browser compilation support from Stencil #4134
Replies: 3 comments 1 reply
-
Yes,
We currently use it to have interactive code documentation in our Design System docs:
Not critical, but definitely a nice to have.
Possibly, but I would prefer not to depend on an external service. I'd be sad to see it go, but as it seems like I'm the only person using it, I don't think it's worth the maintenance burden to keep in. |
Beta Was this translation helpful? Give feedback.
-
|
Given that we're now a few days past the 'close' date for the comment period on this RFC we're going to close it now and consider it 'accepted.' We'll be sharing more soon about what to expect as far as the timeline for removing in-browser compilation support, alternatives to consider to keep using Stencil in the browser, and more. The Stencil team is really excited about the changes and improvements that this will unlock for us in the near future! More on that soon too! |
Beta Was this translation helpful? Give feedback.
-
|
It seems I am late to the party, I was not paying attention this last couple of months because of work... We are also using the in-browser compilation as you are already aware @alicewriteswrongs, since you recently commented on of my open issues related to that #2776. It would make it very hard to upgrade to new versions of stencil without this feature, especially without an alternative in place. WebContainers might be a solution or official integration with storybook. |
Beta Was this translation helpful? Give feedback.
-
|
I have done some preliminary investigation with WebContainers and proved to myself that they do allow running Stencil in the browser without too much difficulty. You can check out the (extremely basic) proof-of-concept I put together here: https://stencil-browser-compile-poc.vercel.app/ the code is here: https://github.com/alicewriteswrongs/stencil-browser-compile-poc Essentially how this works is by simulating a node environment in the browser which lets code written for nodejs run without 'knowing' that it's in the browser at all. You can interact with a node program running inside of a Web Container via a console-like message passing system and you can also create files programmatically from the JS side. My really hacky and quick proof-of-concept work there shows something like that - when you edit the file in the little playground it saves that file inside of the web container and when you press the 'compile' button it calls stencil via a small node script created within the web container and then reads the resulting file. It is a little bit funky and a different type of workflow but I think quite usable for something like this. Hopefully something along these lines can work for you. All of the workflows I know of that use Stencil in the browser I believe will be well-supported by web containers, and given that they simulate a full node environment it should be actually possible to do things in the browser that we don't currently support, like running full stencil builds, comparing the output of different output targets, etc. Do let me know if you have questions about any of this, about using web containers, etc! |
Beta Was this translation helpful? Give feedback.
-
Close date: April 7th, 2023
The Stencil team has been working steadily to address technical debt and longstanding issues with the Stencil codebase. As part of this effort we are proactively identifying key roadblocks which prevent us from making important changes, upgrading dependencies, and fixing bugs.
One feature of Stencil with which we have encountered multiple issues is support for running the compilation step in the browser. For this reason we are strongly considering removing this feature from Stencil, but before doing so we want to gauge the Stencil community's reaction to this proposed change.
We also plan to investigate alternative ways to support the workflows currently supported by this feature, including evaluating WebContainers.
How is in-browser compilation support implemented, and why is it problematic?
Stencil has several dependencies which are written against node.js APIs like the
fsandpathmodules. In order to get these libraries to work in a browser context, the Stencil codebase contains a series of polyfills for these modules and implements an in-memory filesystem which allows reading and writing files in the browser. These polyfills are injected into Stencil at build-time using a custom Rollup plugin.Although this system works at present, it comes with a significant maintenance burden, a burden which the Stencil team has judged to be too high in relation to the benefits of this feature. In particular, dependency upgrades are quite problematic with this system. If a dependency uses, for instance, a function in
fswhich we do not currently polyfill we need to write an implementation for it. Although the polyfills for modules likefsandpathare fairly complete, we have already run into a series of difficult-to-diagnose issues where a function is either not present in our polyfill or its behavior differs in a subtle way from that of the equivalent function in the actual node.jsfsmodule.Difficulties working around the rough edges of this system have already greatly delayed a planned upgrade of Rollup, leaving us on a version which is almost two years old, alongside other problems.
Questions for the Community
At present these are our main questions to the community:
If you don't have concerns about this proposal, feel free to throw a 👍 on this post to indicate your approval!
Beta Was this translation helpful? Give feedback.
All reactions