Use WebContainer API

[ota-meshi]

What is the problem you're trying to solve?

Get the demo working without Heroku.

What solution would you like to see?

I think we can use the WebContainer API that allows us to run Node.js on the browser. https://blog.stackblitz.com/posts/webcontainer-api-is-here/

I did a simple PoC. At least you can check that stylelint can work without a server. https://github.com/ota-meshi/stylelint-demo-poc

[ota-meshi]

I think there are probably other things we need to discuss.

• Do we continue to use Webpack? I used Vite in my PoC repo.
• Do we use React? I built the site using vanilla in my PoC repo. (I personally prefer Vue or Svelte.)
• What features do we need?
  • Make it possible to share reproductions by hash.
  • Also supports SCSS, HTML and more.
  • Make it possible to use configs other than JSON. (I think we can do that with WebContainer)
  • Make dependencies user-modifiable. (I think we can do that with WebContainer)
• How do we design our pages?
  The PoC repository now allows you to view the code after auto-fix. If we were to take our current design and display auto-fixed code, where would we put that panel?

[ybiquitous]

FYI. I'm not sure, but a similar solution is out from CodeSandbox: https://codesandbox.io/blog/announcing-sandpack-2

[jeddy3]

Excellent! Thanks again for rustling up a PoC demo, @ota-meshi.

Get the demo working without Heroku.

👍

Do we continue to use Webpack? I used Vite in my PoC repo.

Vite SGTM. Both SandPack and WebContainers have first-class support for it.

Do we use React? I built the site using vanilla in my PoC repo. (I personally prefer Vue or Svelte.)

It'd be good to go as vanilla as possible so that we align with our reorientation to web languages in 14.0.0; where we changed Stylelint to only support CSS out-of-the-box. Another option is Web Components. @ota-meshi Did you encounter any issues while building the demo by going vanilla?

What features do we need?

It'd be great to have parity with the existing demo site:

• Make it possible to share reproductions by hash.
• Also supports SCSS, HTML and more.

Make it possible to use configs other than JSON.

This would be nice to have as people sometimes create issues using YAML for their configs.

Make dependencies user-modifiable. (I think we can do that with WebContainer)

This is very interesting as people could include plugins and custom syntaxes in their examples.

How do we design our pages?

We can keep the input on the left and output on the right.

body {
  grid: 
   "input"
   "output"
   "problems"
   "config"
}

@media (width > 40em) {
  body {
    grid: 
      "input output"
      "config problems"
      / 1fr 1fr
  }
}

So, autofix output goes top right.

FYI. I'm not sure, but a similar solution is out from CodeSandbox:

Which looks more appropriate for our needs? Sandpack supports Safari, but that's not necessarily a deciding factor.

[ota-meshi]

Did you encounter any issues while building the demo by going vanilla?

Using vanilla is no issue for me. However, I think it's a good to choose a framework that everyone can maintain. If vanilla is okay for everyone, no problem.

We can keep the input on the left and output on the right.

I think I made a mistake in the way the question was asked. Should we respect the current demo site design? For example, the typescript-eslint demo can switch inputs by tabbing. https://typescript-eslint.io/play

What do you think about us using something like tabs as well?

I'm not a designer, so I don't know which one is better. However, since there are many inputs, I think it would be nice to be able to display each input in a larger size by switching between tabs.

[ybiquitous]

FYI. I'm not sure, but a similar solution is out from CodeSandbox:

Which looks more appropriate for our needs? Sandpack supports Safari, but that's not necessarily a deciding factor.

The announcement of Sandpack 2.0 mentions "Difference with WebContainers". While Sandpack supports browsers more widely, WebContainer uses modern browser technologies. I believe Safari would support such technologies in the near future, so adopting WebContainer seems better to me.

Ref: WebContainers Browser Support | WebContainers

[ybiquitous]

I took a glance at the PoC code. Because I feel it's a small app and code touching DOM isn't so many, vanilla seems more maintainable to most people. Updating dependencies would be an additional task if we used some framework.

About the UI design, I'm not particular. I'd like to let your decision.

---

Let me ask a question. We're using <iframe> to show the demo app on stylelint.io (see also the code), does not WebContainer has any limitations about <iframe>?

[ota-meshi]

As far as I understand, <iframe> is not needed. However, I believe we can also expose it as a separate url and use an <iframe>.

However, we need to set some headers. https://webcontainers.io/guides/configuring-headers The setting method for netlify is described in the document. https://webcontainers.io/guides/configuring-headers#netlify

[jeddy3]

What do you think about us using something like tabs as well?

The ESLint TypeScript playground is nice. I hadn't seen it before.

As you said, if we use tabs we'll be able to able to display the chosen input at a larger size. However, the other input will be hidden behind a tab. If we use the current design (but with an extra output panel in the top right), we'll continue to see both inputs at a glance but they will be smaller.

Both approaches have their advantages and disadvantages.

As we:

• mostly use the demo site to view or create small reproducible examples
• only have two inputs: input & config

We should probably keep the existing design so that we can see everything at a glance.

If <iframe> isn't an issue, then WebContainer SGTM as we already have the PoC demo to build on.

[ybiquitous]

If we don’t need to use <iframe>, our website and demo app will be more straightforward! 🙌🏼

[jeddy3]

Lit could be a good fit for UI.

It's close to the platform as a light touch abstraction over Web Components. It encourages using:

• modern CSS language features like custom properties
• bare selectors, and interesting ones like ::slotted and :host.

So that we can use Stylelint on all the CSS of the UI.

[ota-meshi]

only have two inputs: input & config

Make dependencies user-modifiable. (I think we can do that with WebContainer)

This is very interesting as people could include plugins and custom syntaxes in their examples.

Not two inputs. Where do you think the dependency (package.json) input panel should be placed?

[jeddy3]

Oh, I see. Let's go with tabs then.

Shall we use defaults that mimic our getting started docs and demonstrate some of the examples on the home page?

For example:

Input:

a {
  grid-template-areas: 
    "a a"
    "b b b";
   colr: hsla(20deg, 10% 30%, 5%);
}

a {
  --Foo: 1rem;
}

Config:

{
  "extends": ["stylelint-config-standard"]
}

Dependencies:

{
  "devDependencies": {
    "stylelint": "~15.3.0",
    "stylelint-config-standard": "^31.0.1"
  }
}

That should produce problems for 5 of the examples on the home page.

[jeddy3]

Lit could be a good fit for UI.

Having delved into the PoC demo some more, it feels like the vanilla approach used there works well as the monaco-editor does a lot of the UI heavy lifting.

[ota-meshi]

I opened a PR. #352 But I think there are still things to consider. How would you like to deploy this page? Do we still want to use <iframe>? Or do we reference directly from the docs site repo? Do you think this should be componentized if we want to reference it directly from the docs site repo? I think that might be necessary since this repository does not contain the header part of the site.

[ota-meshi]

In componentizing, it might be a good idea for us to use lit, however I have never published anything using lit, so it might take time for me to implement it.

[ybiquitous]

@ota-meshi Thanks for the questions. As you comment, we need to consider some points, especially deployments.

It might be the most simple without using <iframe>. But if not using <iframe>, perhaps we need to embed a new demo app into the Docusaurus page. See also the current demo page code. This way's advantage is that we can preview a pull request code on Netlify before deploying it.

However, this will heavily depend on the Docusaurus build system, so adopting a new build tool or framework may take time and effort.

On the other hand, if we continue using <iframe>, we can adopt a new tool/framework and even develop it on another repository. For example, we may be able to deploy a new demo app to GitHub Pages, and the stylelint.io website may refer to the app via <iframe>.

There may be other better ways. Please let us know if you have more information.

[ota-meshi]

On the other hand, if we continue using <iframe>, we can adopt a new tool/framework and even develop it on another repository. For example, we may be able to deploy a new demo app to GitHub Pages, and the stylelint.io website may refer to the app via <iframe>.

Yeah. I think using an iframe is reasonable at the moment.

However, GitHub Pages doesn't let we specify the header, so we'll need to hack it using something like coi-serviceworker.

In my opinion, if we are using Netlify's Open Source Plan, it would be nice if we could publish a demo page on netlify.

https://www.netlify.com/legal/open-source-policy/

[jeddy3]

Continuing to use an <iframe> to keep the demo and website codebases separate, and publishing the demo to Netlify both SGTM.

I've created a new deployment under the Stylelint org on Netlify: chimerical-trifle-8d3c21

If we add a netlify.toml with the build settings to https://github.com/stylelint/stylelint-demo/pull/352, we should get a deploy preview.

[ota-meshi]

I added the netlify.toml file, but I can't do build settings. Could you change the following from settings?

• Build settings:
  • Build command: npm run build
  • Publish directory: dist

[jeddy3]

I pushed a commit to do it.

Deploy preview at: https://deploy-preview-352--chimerical-trifle-8d3c21.netlify.app/

It's looking fantastic, btw! Thank you so much for all the work you've put into it already!

I'll hopefully have time this weekend to delve into your pull request. I hope to bring the design in line with the website.

[ota-meshi]

I pushed a commit to do it.

Thank you! I didn't know that netlify.toml can do build configs 😅

[ota-meshi]

@ybiquitous @kristerkari We can check that it can also be used as a demo for stylelint-scss.