In stylelint/stylelint#6743 (comment):

It might be good timing to publish also create-stylelint: 0.2.0...main

I agree! Happy to do the release process for this one if we'd like. It seems like the workflow is:

1. update changelog
2. update package.json
3. push to npm

If we think this is a good idea, I can open a "Prepare 0.3.0" PR (or commit) that does the first two items.

I think we can release this initial version.

What is the problem you're trying to solve?

Most tools that perform destructive actions have a --dry-run option, where the tool prints out everything it would have done normally, but doesn't actually touch the filesystem (or perform other actions). This can be helpful to validate how the tool would work before committing to it, or debugging.

In implementing #1, I tabled this feature for a follow-up.

What solution would you like to see?

A --dry-run option for this tool.

Since this would be one of our first options, we can decide what our approach is for argument parsing; I've seen yargs used frequently, including in create-astro. That being said, I'm not wedded to any implementation.

I'm happy to contribute this feature, especially as it's a follow-up to #1.

• happy path
• failure during installation (I think I'll have to mock execa for this)

Ref: #1 (comment)

I will sync labels in this repository with other repositories int https://github.com/stylelint org.

See https://github.com/stylelint/.github#syncing-labels for the task details.

npx github-label-sync stylelint/stylelint-create

What minimal example or steps are needed to reproduce the bug?

npm init stylelint
npx: installed 76 in 8.406s
/home/db/.npm/_npx/583809/lib/node_modules/create-stylelint/create-stylelint.mjs:5
import process from 'node:process';
^^^^^^^

SyntaxError: Unexpected identifier
at Module._compile (internal/modules/cjs/loader.js:723:23)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Function.Module.runMain (internal/modules/cjs/loader.js:831:12)
at startup (internal/bootstrap/node.js:283:19)
at bootstrapNodeJSCore (internal/bootstrap/node.js:623:3)

What minimal configuration is needed to reproduce the bug?

1- Fresh Ubuntu 20.04.5 LTS
2- sudo apt-get install nodejs
3- sudo apt-get install npm
4- npm init stylelint

How did you run Stylelint?

npm init stylelint

Which Stylelint-related dependencies are you using?

None

What did you expect to happen?

To install stylelint

What actually happened?

Error

Do you have a proposal to fix the bug?

No response

What is the problem you're trying to solve?

Currently, the tool assumes a standard vanilla CSS setup. This may not work for projects that use SCSS (among other preprocessors, etc.).

What solution would you like to see?

In stylelint/stylelint#4269 (comment), @Jeddy mentioned:

Then we can add a flag for SCSS, e.g.

npm init stylelint -- --template scss

This seems like a good idea to me, though also happy to workshop what it'd be named, etc.

In addition, are there other templates that we should consider?

Happy to contribute this feature as well!

What is the problem you're trying to solve?

In #1, I implemented a rough heuristic to check if the user already has Stylelint configured: by checking the current working directory for a set of files. However, this ignores several areas that Stylelint users could configure their configurations in, including the stylelint property in package.json.

What solution would you like to see?

In #1 (comment), @ntwb said:

Potentially additional files and paths based on cosmiconfig:
https://github.com/davidtheclark/cosmiconfig/#cosmiconfig

• "any of the above two inside a .config subdirectory"
• "a .config.js or .config.cjs CommonJS module"

i.e., we could use cosmiconfig to detect a valid Stylelint configuration in the CWD.

There may also be a different approach that I'm missing; though, keeping exact parity with Stylelint seems like a good idea.

Regardless of whatever approach we pick, I'm happy to take this on, especially as it's a follow-up to #1.