Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Pete Gonzalez
    @octogonz
    Hmmm...
    Kirill Popolov
    @ezhikov

    Hi. I'm considering to migrate from lerna to rush and a bit confused on some points.

    First question is about common dependencies and build tools. In lerna you just install tools such as typescript, prettier and eslint at top level and then run in every package or on all code at once. In rush-stack repo I see .eslintrc files in every package, but I don't see eslint installed. Where should I keep it? How would I run it? Same thing goes with prettier, typescript and pretty much every other such tool.

    Next, I can't figure out how to include storybook. In our current workflow we have storybook installed on top level, so in dev mode it will pick up everything from monorepo subfolders and rebuild on any changes. Not sure how to properly set up this in case of Rush.

    Pete Gonzalez
    @octogonz
    The single-threaded tool that wants to do a brute-force scan of every single source file tends to be a performance bottleneck in a large repo, because it cannot be parallelized or participate in incremental builds. (Prettier is an exception because it is usually applied to Git commit diffs, versus specific projects.) So as much as possible Rush tries to treat each project folder as its own build problem. But a lot of that is left to the user today. Through the new Rush Stack effort we are working to improve this, e.g. last summer we made a reusable ESLint ruleset that can be invoked in each folder separately.
    But to answer your question, top-level scripts are possible and there are plenty of good reasons to use them. The short answer is you can simply create a special project folder where they run, with a package.json specifying their dependencies.
    The more sophisticated approach is to code those scripts in TypeScript and treat then like a real project, which can be published to an internal registry and installed using install-run.js
    Kirill Popolov
    @ezhikov
    Do you mean that I create separate project where my typescript, eslint and other tools live and then invoke them as binaries from that package?
    Trey Long
    @xealot
    Is there a trick to get rush to link in local packages? I have several scoped local packages that I'm trying to split a big repo into, but seemingly no combination of rush build rush link or rush install creates the symlink in node_modules
    Trey Long
    @xealot
    rush install -p is the only thing that links those projects in.
    William Bernting
    @wbern
    Related to Trey's Q, can you do rush link without doing rush update?
    Not sure why it's not working for you Trey.. Are the version selectors correct? Also don't understand "trying to split a big repo into"
    Trey Long
    @xealot
    This is because I'm using Yarn, Rush does not play super well with it.
    Renoir Boulanger
    @renoirb

    Hey @ezhikov, I've been there too. Migrated from Lerna to Rush. With same requirements: common/shared build dependencies. I've been able to make it work with all TypeScript, Rollup, Babel etc. For all types, all modern, even JavaScript (TypeScript supports them with allowJs).

    You can play with a small project that has build utilities, including common eslint, jest, rollup config as simple as I could. Months or work. The result is publicly visible here

    https://github.com/renoirb/experiments-201908-rush-typescript-just-bili-monorepo/

    It publishes a few packages:

    Packages using them:

    Notice the date-epoch and url-dirname-normalizer how the content of eslintrc, bili (rollup) is small.

    I hope that'll help

    Here is another one where I'm using @renoirb/conventions-use-bili, and even Rush.js' @microsoft/node-core-library's JsonSchema loader https://gitlab.com/renoirb/renoirb-particles/-/blob/master/libraries/jsonschema-aware-loader/package.json
    Renoir Boulanger
    @renoirb
    Also, for even more recent than the experiments-201908-rush-typescript-just-bili-monorepo, I'm refactoring a personal project leveraging recent knowledge, @ezhikov, you can cherry-pick patterns there too: https://github.com/renoirb/archivator/tree/re-rework
    Josh Biddick
    @sadsa

    I'm getting an error when using @microsoft/gulp-core-build which is throwing

    Error - [tsc] ../../common/temp/node_modules/.pnpm/registry.npmjs.org/@jest/core/24.9.0/node_modules/@jest/core/build/cli/index.d.ts(10,53): error TS2694: Namespace 'yargs' has no exported member 'Arguments'.

    It seems there are multiple versions of @types/yargs installed but the 0.0.34 typings file is being resolved

    Anyone experienced this issue? It's currently preventing us from running any jest tests
    Kirill Popolov
    @ezhikov
    @renoirb, thank you for your links. Looks like I have a lot of examples to dive into :)
    Renoir Boulanger
    @renoirb
    There aren't many yet.
    I've been using and migrated a few tens of packages using this. Most of them are corporate work stuff. But, for example, the @renoirb/conventions-use-bili i've made it public. It helps me have same build steps even for non webpack bublished modules. Or babel. Or vue components.
    I wanted to have one file and just minimum things, no 100 lines and change a word or two.
    ... times all packages using it
    Devin Fee
    @dfee
    @renoirb couple thoughts – how's your mileage been w/ command-line.json, and how are you handling versioning?
    also, your conventions concept seems pretty neat.
    Pat White
    @patwhite
    Hey everyone! I'm just learning about rush, have read a lot of the documentation, had a few questions. In particular, I'm trying to see if rush is appropriate for a mono-repo of microservices, and how to manage things like testing, deployment, etc.
    I found this issue which seems like they're asking the same question: microsoft/rushstack#884
    Good conversation, but open since 2018, is this use case of mono-repo for a collection of microservices not really the main use case?
    Josh Biddick
    @sadsa
    Is there any way that RushJS can show a warning when the project's package.json file contains dependencies that are already required by projects they are depending on? i.e. When running rush updatean error will be displayed preventing the user from having more than one version of the package installed?
    Pete Gonzalez
    @octogonz

    Good conversation, but open since 2018, is this use case of mono-repo for a collection of microservices not really the main use case?

    @patwhite I think the simplest way to accomplish this would be to run rush change but skip rush publish. This will do all the steps of bumping versions and preparing change logs, but without actually publishing to NPM. Docs are here. For sample example command-lines, check out buildAndPublish.yaml from our repo.

    Is there any way that RushJS can show a warning when the project's package.json file contains dependencies that are already required by projects they are depending on? i.e. When running rush updatean error will be displayed preventing the user from having more than one version of the package installed?

    @sadsa It sounds like you're asking for the ensureConsistentVersions setting (docs here). This will ensure that if one project in your repo declares a certain package dependency, then any other projects that want that dependency must request the exact same version. (And then if you want to make exceptions for certain versions, there is also an allowedAlternativeVersions setting you might want to look at.)

    The way that you worded your question suggests that you might intend for a package to import dependencies that are not declared in its package.json, expecting them to be found in the node_modules folder because some other dependency declared them. These are called phantom dependencies -- they are a legacy NPM behavior that is not recommended. Rush actually implements safeguards to prevent this practice.

    Patrick Berkeley
    @patrickberkeley
    Is there a way to pass allowWarningsInSuccessfulBuild to the built in build and rebuild commands?
    or would I need to write a custom command with that option that wraps the defaults
    Pete Gonzalez
    @octogonz
    I feel like that should be working as of microsoft/rushstack#1485 which makes it so that the predefined build/rebuild commands can be updated using command-line.json without having to completely redo their specification.
    @patrickberkeley Are you using the latest Rush?
    Josh Biddick
    @sadsa
    Hey guys, I'm seeing some very strange behaviour when running @microsoft/gulp-build-core whereby a module is being resolved as {} i.e. an empty object. After a day of searching I found this thread https://stackoverflow.com/questions/21056748/seriously-debugging-node-js-cannot-find-module-xyz-abcd/21057355#21057355 which states there are some issues with the way node resolved packages installed with npm link. Anyone else had any similar issues?
    Pete Gonzalez
    @octogonz
    Do you have a repro branch that you could share?
    matthiasg
    @matthiasg
    If I wanted to execute the local pnpm (specifically the pnpm pack command) from a command in the command-line.json how would I need to configure that to remain stable ?
    matthiasg
    @matthiasg
    @sadsa are you using some sort of tree shaking ? We were using rollup and when tree shaking it caused empty objects (without prototype) in some libraries
    matthiasg
    @matthiasg

    I converted my projects into one big rush repo. How do I now manually bump all versions of all included packages to e.g 2.0.0-alpha.1 ? rush change does not yet find changes, rush publish doesn't do anything, rush version only updates the version in the version-policies.json file ?

    Can anybody give me an example ?

    Patrick Berkeley
    @patrickberkeley
    @octogonz we are on 5.20.0. Yes that is exactly what we need. I didn't imagine (or try) overriding the built-in commands without redoing their specification. Thanks!
    William Bernting
    @wbern
    Is anyone using prettier and managing to put prettier plugins in a centralized place in the repo, which isn't in the root?
    Josh Biddick
    @sadsa
    @matthiasg - I managed to find and fix the issue and actually created a bug for it here - microsoft/rushstack#1778
    Devin Fee
    @dfee
    just want to share a bizarre experience i have.
    rush install -p grommet // error: requires peer of styled-components
    rush install -p styled-components // error: requires peer of react-is
    rush install -p react-is // OK, let's go back up the stack
    rush install -p styled-components // OK, round 2
    rush install -p grommet // OK, round 2
    it's like middleware... but i'm the operator :D
    Artem Kobzar
    @JSMonk
    Hello guys. I have a question. How could I link package build directory via rush link instead of the package directory?
    William Bernting
    @wbern
    @JSMonk the rush link command is pretty limited. There are better ways to do symlinking with other packages in the wild, combined with rush-lib. What do you want to do exactly?
    Artem Kobzar
    @JSMonk
    I need to build a package and link build directory for other packages
    William Bernting
    @wbern
    Is there a reason why the other packages cannot import your source package the standard way, then referencing the build directory either via the main attribute in package.json or via path?
    Mihail Malo
    @qm3ster
    IMG_20181021_110734.jpg
    Pete Gonzalez
    @octogonz
    Nice! 😋
    William Bernting
    @wbern
    The monoraaaaail