| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Publishing under an org stays the recommendation, since naming the package `sv` within it enables the `sv add @my-org` shorthand, but it is no longer required. Corrects the docs, which marked `sv add my-lib` as invalid even though unscoped specifiers have always resolved. Closes #1101
|
Install the latest version of sv from ab075c4: pnx https://pkg.svelte.dev/sv/c/ab075c4123cccc36fe1cb494518c0a04dc39a22d createOpen in pkg.svelte.dev: https://pkg.svelte.dev/repos/cli/pr/1279 |
Sorry, something went wrong.
🦋 Changeset detectedLatest commit: ab075c4 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
Sorry, something went wrong.
Sorry, something went wrong.
|
is it intentional that running sv create @foobar/sv --template addon creates this directory structure: @foobar
└── sv
├── package.json
├── README.md
└── ...other files
...where the org is its own directory. if not, then I wonder what we should do instead? perhaps it should just create the sv dir without the org scope? perhaps @foobar-sv instead? i'm not sure what the right answer is at the moment |
Sorry, something went wrong.
|
I'm glad that you bring this up, because I also don't know the best answer (but I remember that this topic it not that trivial) I think that we should be able to distinguish 2 things: directory & package name. But sv create I/want/this/location is creating nested folder... so my changing? Maybe if it's starting with @ and having only one / we could create a folder sv only ? just thinking loud, I'm not sure |
Sorry, something went wrong.
|
We can also distinguish between an empty cwd and an existing monorepo. Also, the current implementation has too much magic under the hood. We should explain it if we're going to create multiple nested folders. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Closes #1101.
The org prompt in sv create --template addon now accepts an empty answer and scaffolds an unscoped package. Publishing under an org stays the recommendation, since naming the package sv within it is what enables the sv add @my-org shorthand.
Also corrects the ### Package names docs. They marked npx sv add my-lib as invalid, but sv add has parsed unscoped specifiers since the feature shipped and has never had a scope check. Two add-ons published today under the sv-add keyword are unscoped (sveltekit-temporal, svforge) and install fine.
For context on how the docs drifted: the requirement was only ever enforced in create (added in 618f1ad, relaxed to a prompt by #1031), while the docs stated it globally. A later docs refactor (#1161) then turned the hedged "unscoped packages are not supported yet" note into a hard ✗ BAD npx sv add my-lib example, pointing at the one command that never enforced it.
Note that the prompt still blocks in non-interactive runs; that is pre-existing and left alone here.