feat: `create-svelte` support for scoped packages #4851

elliott-with-the-longest-name-on-github · 2022-05-08T08:08:21Z

Currently create-svelte does not support creating projects with scoped names, i.e. @my-fancy-scope/my-fancy-package. This is a crack at fixing that in a way that's as un-frustrating to developers as possible.

The current approach is to try to turn the base path of the provided project location into a package name. This has some weird edge cases, and is especially gross with @scope/package semantics, as that's obviously two folders (or a folder and a file with no extension) from a filesystem perspective.

For ease of understanding, here's the current behavior vs. the new behavior:

Current
- Accept the project path as the first positional argument
- If that's not provided, ask for a path to put the project in
- Do our best to yoink the package name from the provided path (eg. ./@myscope/mypackage becomes mypackage, and ./.my folder name with spaces becomes my-folder-name-with-spaces).
New
- Continue to accept the project path as the first positional argument
- Prompt user for package name. Use a validator to make sure the provided name is valid (accepts both scoped and normal package names).
  - This does NOT kick the user out of the interface for providing a bad package name -- it just provides a descriptive error message and prevents them from continuing until they provide a valid one.
- If the user provided the CLI folder path, continue as normal using that folder.
- If not:
  - Prompt the user Where should we create your project? (leave blank to use default: ${provided_package_name})
  - If blank, use the provided package name as the folder. Else, use the provided folder.Examples:
    - @my-scope/my-package => ./@my-scope/my-package
    - my-package => my-package
    - All package characters are allowed filesystem characters, so there shouldn't be any problems with this approach.

All in all, this adds one prompt and makes the project naming much more user-controllable. At worst, it requires typing out one more answer than current -- at best, it's still the same number of inputs.

One other fringe benefit of this is that the to_valid_package_name (and the scoped package edge-cases that come with it) function is no longer needed at all -- since the package name is validated at the CLI, we know it's a valid package name already.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
This message body should clearly illustrate what problems it solves.
Ideally, include a test that fails without this PR but passes with it.

Tests

Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

changeset-bot · 2022-05-08T08:08:24Z

🦋 Changeset detected

Latest commit: 036752d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
create-svelte	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Mlocik97 · 2022-05-08T08:37:52Z

packages/create-svelte/bin.js

+					const regex = new RegExp(/^(@[a-z0-9-~][a-z0-9-._~]*\/)?[a-z0-9-~][a-z0-9-._~]*$/);
+					const match = regex.test(value);
+					return !match
+						? 'Value is not a valid NPM package name. Package names must be lowercase and one word, and may contain hyphens and underscores, or be scoped and of the form @scope/package.'


isn't match already boolean value? Also I don't know if You want to put error message here.

return match ?? 'Value is not...'

Ah, you're sort of right. The error message would never be returned with ?? (nullish coalescing) -- but I should be using matched || "Blah blah blah". I'll fix it later.

packages/create-svelte/index.js

dominikg · 2022-05-08T08:57:36Z

Some thoughts:

If you use create-svelte to initialize an application, asking for a package name isn't really relevant and could be confusing. In fact if the user doesn't want to publish a package, it would be best if "private": true was set to prevent mishaps

If you use it to initialize a library, esp. within an org, it is very likely that the org directory already exists on disk and you run pnpm create svelte inside that, so creating a deep path might backfire (or users prefer it without the @ prefix).

If we end up asking for a package name and validating it, this one is the official utility to do so: https://github.com/npm/validate-npm-package-name

dominikg · 2022-05-08T08:59:12Z

packages/create-svelte/bin.js

+				name: 'packagename',
+				message: 'What would you like to name your project?',
+				validate: (value) => {
+					const regex = new RegExp(/^(@[a-z0-9-~][a-z0-9-._~]*\/)?[a-z0-9-~][a-z0-9-._~]*$/);


~ is no longer allowed for new packages, see https://github.com/npm/validate-npm-package-name

Interesting! That's probably a second bug fix for us -- the current function we're using to convert folder names to package names is still allowing them. I'll likely change this implementation to use the library you linked in your top level comment anyway -- I didn't realize that was an official NPM library when I saw it!

elliott-with-the-longest-name-on-github · 2022-05-08T15:35:49Z

If you use create-svelte to initialize an application, asking for a package name isn't really relevant and could be confusing.

I'd agree... to an extent?

IMO, if you're creating a Node application, the package name is always relevant, but others may disagree. (More below.)

In fact if the user doesn't want to publish a package, it would be best if "private": true was set to prevent mishaps

I'm not really sure what mishaps we'd be preventing (oops, I accidentally went all the way through the multistep process of releasing a package when it was supposed to be private? 😂). Maybe I'm just not thinking of something obvious.

If you use it to initialize a library, esp. within an org, it is very likely that the org directory already exists on disk and you run pnpm create svelte inside that, so creating a deep path might backfire (or users prefer it without the @ prefix).

Yeah, I supposed what the default is depends on what people are normally doing. I normally run npm create svelte from my repos directory and then provide my package name as the response to "where should we create it" -- which doesn't work for scoped packages. Even so, npm init svelte . is two characters longer and will initialize the project in the current directory without prompting for a location. 🙂

If we end up asking for a package name and validating it, this one is the official utility to do so: https://github.com/npm/validate-npm-package-name

Thank you! I'm going to incorporate this into this PR.

Just to add to the discussion and source your feedback (and @Mlocik97's as he seems pretty invested in this one):

I cannot think of a better way to support scoped packages. No matter what, it seems like there's no way to get around asking for a package name. Deriving a scoped package from the file system seems error-prone and confusing. You could add a second prompt after asking for the location ("Would you like the current package name?: ${package_name_derived_from_folder}"), but that still involves a second prompt that, unlike the current implementation, can't be skipped by providing an argument to the CLI.

The only other palatable option I could think of is providing an override package name to the CLI as the second positional argument (npm init svelte . @my-scope/my-package), but that seems... hidden.

If we don't want to support scoped package names at all, we can just close this PR and the associated issue. 🙂

Mlocik97 · 2022-05-08T17:16:17Z

Yeah, I supposed what the default is depends on what people are normally doing. I normally run npm create svelte from my repos directory and then provide my package name as the response to "where should we create it" -- which doesn't work for scoped packages. Even so, npm init svelte . is two characters longer and will initialize the project in the current directory without prompting for a location. 🙂

I really don't know what is bad about this... how npm init svelte vs npm init svelte . works is actually correct for me... I wouldn't change this.

I cannot think of a better way to support scoped packages. No matter what, it seems like there's no way to get around asking for a package name. Deriving a scoped package from the file system seems error-prone and confusing.

How, npm init -y does it. Yeah they don't validate it, but they still derive it. I expect same for every npm init <something>. It definitelly should be derived and user shouldn't be asked for package name, as dominikg already said. It could be even more confusing behavior. Let make behavior as close to npm init -y as possible. Consistency is important...

I already wrote how it should work (in original issue), and I don't think it's bug-prone or confusing, actually opposit.

Mlocik97 · 2022-05-08T17:24:10Z

What behavior I expect is:

1 npm init svelte inside my-app folder.

will generate app inside that folder and set pkg.name to my-app.

npm init svelte inside som@eap# folder

will generate app inside that folder and set pkg.name to som-eap

npm init svelte @comp/someapp

will generate app inside someapp folder and set pkg.name to @comp/someapp

npm init svelte @com#s/s@app/thing

will generate app inside s@app/thing folder and set pkg.name to @com-s/s-app-thing

npm init svelte some/app

will generate app inside some/app and set pkg.name to app

and that all without additional input needed (if user don't want to change it)

Mlocik97 · 2022-05-08T19:07:22Z

actually I got another idea.

What about having it all as it is now... aka exactly how to_valid_package_name() works, but do something like:

const scope = process.argv[3];

pkg.name = scope
              ? `@${to_valid_package_name(scope)/to_valid_package_name(name)}`
              :  to_valid_package_name(name);

this would works perfectly I think, would actually do everything we want... npm init svelte my-app would work exactly as now,... but npm init svlte my-app company-name would generate my-app folder but @company-name/my-app pkg.name.

Easy to implement, derivation work, and it's simple for both projects without scope and with one (for packaging).

@tcc-sejohnson @dominikg

elliott-with-the-longest-name-on-github · 2022-05-08T19:18:46Z

@Mlocik97

I had a similar idea that I like slightly better.

Right now, the CLI looks like:

npm init svelte {path}

We just update it to look like (similar but not identical to your suggestion):

npm init svelte {path} {packageNameOverride}

For calls that specify path but not a package name override, we'll parse the package name from the path as we currently do (with an update that checks to see if the second folder from the leaf starts with an @ - if it does, it'll parse it as a scoped package).

For calls that specify a path and a package name, it'll use both verbatim (obviously validating the package name argument).

Give me some time today to implement. I think it's the cleanest solution -- the CLI will still work exactly as it currently does, but with the option to specify the package name separate from the path on the CLI.

dominikg · 2022-05-08T19:55:44Z

Please do not put work into this before it was discussed and decided if create-svelte should support it and how exactly.

more alternatives

just leave it as is and you'll just update package.json manually after create-svelte is done. It's a one-time one-line edit for you keeps create-svelte small and doesn't ask unrelated questions to new users who might not even know about npm package scopes
create a custom starter template for your scope and clone that instead of using create-svelte
build a different cli that asks advanced questions

Mlocik97 · 2022-05-09T08:47:47Z

dominkg

if it would be introducing another param, I don't think it's problem. without that param whole create-svelte would works exactly as it does now. So I don't see any breaking change or confusion... we just introduce another param for scope or pkg.name overwrite. I don't see how this would be problematic.

tcc-sejohnson

I don't think dominikg said this PR is wrong, more than he said they need time to discuss it with team to decide how it will work.

elliott-with-the-longest-name-on-github · 2022-05-10T00:32:28Z

@Mlocik97

I understand! I still have the work saved. I would rather not clog up the PR list (it's already pretty long). Whenever the maintainers join the discussion on the linked issue, if they decide to support a change, I'll open a new PR. They seem pretty overwhelmed (not in a bad way!) with the number of issues/PRs open in the 1.0 milestone right now, so I didn't want to have something requiring additional discussion open. If/when they tag more "help wanted" issues (or when I find a way to get in on conversations involving non-help-wanted issues), I'll jump on them.

elliott-with-the-longest-name-on-github added 2 commits May 8, 2022 01:51

feat: create-svelte support for scoped packages

c0a1cd9

feat: Changeset

036752d

elliott-with-the-longest-name-on-github changed the title ~~feat: create-svelte support for scoped packages~~ feat: create-svelte support for scoped packages May 8, 2022

vercel bot deployed to Preview – kit May 8, 2022 08:08 View deployment

vercel bot deployed to Preview – kit-svelte-dev May 8, 2022 08:08 View deployment

elliott-with-the-longest-name-on-github mentioned this pull request May 8, 2022

create-svelte's to_valid_package_name modifies valid package names #4754

Closed

Mlocik97 reviewed May 8, 2022

View reviewed changes

packages/create-svelte/index.js Show resolved Hide resolved

dominikg reviewed May 8, 2022

View reviewed changes

elliott-with-the-longest-name-on-github closed this May 8, 2022

elliott-with-the-longest-name-on-github deleted the sejohnson-create-svelte-allow-scoped-packagenames branch May 8, 2022 21:47

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

feat: `create-svelte` support for scoped packages #4851

feat: `create-svelte` support for scoped packages #4851

Uh oh!

elliott-with-the-longest-name-on-github commented May 8, 2022

Uh oh!

changeset-bot bot commented May 8, 2022

Uh oh!

Mlocik97 May 8, 2022 •

edited

Loading

Uh oh!

elliott-with-the-longest-name-on-github May 8, 2022

Uh oh!

Uh oh!

dominikg commented May 8, 2022

Uh oh!

dominikg May 8, 2022

Uh oh!

elliott-with-the-longest-name-on-github May 8, 2022

Uh oh!

elliott-with-the-longest-name-on-github commented May 8, 2022

Uh oh!

Mlocik97 commented May 8, 2022

Uh oh!

Mlocik97 commented May 8, 2022 •

edited

Loading

Uh oh!

Mlocik97 commented May 8, 2022 •

edited

Loading

Uh oh!

elliott-with-the-longest-name-on-github commented May 8, 2022

Uh oh!

dominikg commented May 8, 2022

Uh oh!

Mlocik97 commented May 9, 2022

Uh oh!

elliott-with-the-longest-name-on-github commented May 10, 2022

Uh oh!

Uh oh!

Uh oh!

feat: create-svelte support for scoped packages #4851

feat: create-svelte support for scoped packages #4851

Uh oh!

Conversation

elliott-with-the-longest-name-on-github commented May 8, 2022

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

Tests

Changesets

Uh oh!

changeset-bot bot commented May 8, 2022

🦋 Changeset detected

Uh oh!

Mlocik97 May 8, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elliott-with-the-longest-name-on-github May 8, 2022

Choose a reason for hiding this comment

Uh oh!

Uh oh!

dominikg commented May 8, 2022

Uh oh!

dominikg May 8, 2022

Choose a reason for hiding this comment

Uh oh!

elliott-with-the-longest-name-on-github May 8, 2022

Choose a reason for hiding this comment

Uh oh!

elliott-with-the-longest-name-on-github commented May 8, 2022

Uh oh!

Mlocik97 commented May 8, 2022

Uh oh!

Mlocik97 commented May 8, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Mlocik97 commented May 8, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

elliott-with-the-longest-name-on-github commented May 8, 2022

Uh oh!

dominikg commented May 8, 2022

Uh oh!

Mlocik97 commented May 9, 2022

Uh oh!

elliott-with-the-longest-name-on-github commented May 10, 2022

Uh oh!

Uh oh!

feat: `create-svelte` support for scoped packages #4851

feat: `create-svelte` support for scoped packages #4851

Mlocik97 May 8, 2022 •

edited

Loading

Mlocik97 commented May 8, 2022 •

edited

Loading

Mlocik97 commented May 8, 2022 •

edited

Loading