Add support for scoped packages #266
Labels
question
Further information is requested
Comments
|
Hey sorry for confusion, but this already works this way. See Make sure you're correctly specifying the flag value with equal sign me quote, no space in between. https://turborepo.org/docs/reference/command-line-reference#option-syntax https://turborepo.org/docs/reference/command-line-reference#--scope |
|
It works! 🙌🏻 Thanks :) This might have been documented in a more straight forward way, or just work out of the box though – as future improvement points or whatever. Thank you for the quick support! |
|
Agree with @selbekk that my first impression is it would be nice if just work out of the box. Not sure if there is any downside yet |
sokra
pushed a commit
that referenced
this issue
Oct 25, 2022
Upgrading SWC deps because we need swc-project/swc#5499 for #252 This also switches from using the JSX preset to the full React preset. @sokra noticed a drop in performance in #252 and one possible reason is the difference in processing between the SWC versions, or between the presets, so this PR acts as a way to isolate that particular change for benchmarks.
sokra
pushed a commit
that referenced
this issue
Oct 25, 2022
This PR implements HMR support with React Refresh built-in. For now, in order for React Refresh to be enabled, you'll need the `@next/react-refresh-utils` package to be resolveable: `yarn add @next/react-refresh-utils` in your app folder. * Depends on #266 * Integrated both HMR-and-React-Refresh-specific logic directly into the ES chunks' runtime. Webpack has more complex setup here, but for now this makes the logic much more easy to follow since everything is in one place. I have yet to implement the "dependencies" signature for `hot.accept`/`hot.dispose`, since React Refresh does not depend on them. We'll have to see if they're even used in the wild or if we should deprecate them. * Only implemented the [module API](https://webpack.js.org/api/hot-module-replacement/#module-api), not the [management API](https://webpack.js.org/api/hot-module-replacement/#management-api). We apply all updates as soon as we receive them. * Added support for "runtime entries" to ES chunks. These are assets that will be executed *before* the main entry of an ES chunk. They'll be useful for polyfills in the future, but for now they're here to evaluate the react refresh runtime before any module is instantiated. Next steps for HMR: * Implement CSS HMR * Implement (or decide to deprecate) the [dependencies form](https://webpack.js.org/api/hot-module-replacement/#accept) of `hot.accept`/`hot.dispose` * Clean up `runtime.js` some more: switch to TypeScript, split into multiple files, etc. It'd be nice if all of this could be done at compile time, but how to achieve this is unclear at the moment. _Can we run turbopack to compile turbopack?_
jridgewell
pushed a commit
to vercel/next.js
that referenced
this issue
Mar 10, 2023
This PR implements HMR support with React Refresh built-in. For now, in order for React Refresh to be enabled, you'll need the `@next/react-refresh-utils` package to be resolveable: `yarn add @next/react-refresh-utils` in your app folder. * Depends on vercel/turborepo#266 * Integrated both HMR-and-React-Refresh-specific logic directly into the ES chunks' runtime. Webpack has more complex setup here, but for now this makes the logic much more easy to follow since everything is in one place. I have yet to implement the "dependencies" signature for `hot.accept`/`hot.dispose`, since React Refresh does not depend on them. We'll have to see if they're even used in the wild or if we should deprecate them. * Only implemented the [module API](https://webpack.js.org/api/hot-module-replacement/#module-api), not the [management API](https://webpack.js.org/api/hot-module-replacement/#management-api). We apply all updates as soon as we receive them. * Added support for "runtime entries" to ES chunks. These are assets that will be executed *before* the main entry of an ES chunk. They'll be useful for polyfills in the future, but for now they're here to evaluate the react refresh runtime before any module is instantiated. Next steps for HMR: * Implement CSS HMR * Implement (or decide to deprecate) the [dependencies form](https://webpack.js.org/api/hot-module-replacement/#accept) of `hot.accept`/`hot.dispose` * Clean up `runtime.js` some more: switch to TypeScript, split into multiple files, etc. It'd be nice if all of this could be done at compile time, but how to achieve this is unclear at the moment. _Can we run turbopack to compile turbopack?_
jridgewell
pushed a commit
to vercel/next.js
that referenced
this issue
Mar 10, 2023
sokra
pushed a commit
to vercel/next.js
that referenced
this issue
Mar 13, 2023
This PR implements HMR support with React Refresh built-in. For now, in order for React Refresh to be enabled, you'll need the `@next/react-refresh-utils` package to be resolveable: `yarn add @next/react-refresh-utils` in your app folder. * Depends on vercel/turborepo#266 * Integrated both HMR-and-React-Refresh-specific logic directly into the ES chunks' runtime. Webpack has more complex setup here, but for now this makes the logic much more easy to follow since everything is in one place. I have yet to implement the "dependencies" signature for `hot.accept`/`hot.dispose`, since React Refresh does not depend on them. We'll have to see if they're even used in the wild or if we should deprecate them. * Only implemented the [module API](https://webpack.js.org/api/hot-module-replacement/#module-api), not the [management API](https://webpack.js.org/api/hot-module-replacement/#management-api). We apply all updates as soon as we receive them. * Added support for "runtime entries" to ES chunks. These are assets that will be executed *before* the main entry of an ES chunk. They'll be useful for polyfills in the future, but for now they're here to evaluate the react refresh runtime before any module is instantiated. Next steps for HMR: * Implement CSS HMR * Implement (or decide to deprecate) the [dependencies form](https://webpack.js.org/api/hot-module-replacement/#accept) of `hot.accept`/`hot.dispose` * Clean up `runtime.js` some more: switch to TypeScript, split into multiple files, etc. It'd be nice if all of this could be done at compile time, but how to achieve this is unclear at the moment. _Can we run turbopack to compile turbopack?_
sokra
added a commit
to vercel/next.js
that referenced
this issue
Mar 13, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the feature you'd like to request
I would like to release my packages under an npm scope - like
@myorg/reactand@myorg/lint-rules.Right now, I can't figure out a way to do that with TurboRepo, because it can't resolve repos whenever I add a scope to the front of a package name.
I'm not sure if this is a feature or a bug request - kind of both, because I feel like this should be a pretty common use case for Turborepo users.
Describe the solution you'd like
I would like to specify the name of the package in its
package.json- like@myorg/react- and that should make it available under that name in other parts of the monorepo.I would prefer if the name of the package didn't have to be parroted to the folder name - so that my file structure would continue to be
packages/react:)Describe alternatives you've considered
I can't think of any other alternatives, other than not scoping our packages (not an option for us).
The text was updated successfully, but these errors were encountered: