Lifecycle scripts for hosted git and local dependencies not run on install #5235
Assignees
Labels
Comments
ghost
assigned 
|
@rtsao I think I just ran into this issue, do you know if there's any workaround for it? Otherwise I was just going to vendor the code I wanted from a Github repo |
MaxGabriel
added a commit
to MaxGabriel/react-tokeninput
that referenced
this issue
Feb 2, 2018
wKovacs64
added a commit
to wKovacs64/hibp
that referenced
this issue
Mar 16, 2018
* works in npm 5 * fails in yarn, see yarnpkg/yarn#5235
wKovacs64
added a commit
to wKovacs64/hibp
that referenced
this issue
Mar 16, 2018
* works in npm 5 * broken in yarn, see yarnpkg/yarn#5235
pvinis
added a commit
to pvinis-archive/chrome-headless-render-pdf
that referenced
this issue
Apr 1, 2018
taras
added a commit
to taras/d3-collection
that referenced
this issue
Apr 3, 2018
emilioastarita
added a commit
to emilioastarita/mr-emoji
that referenced
this issue
Apr 8, 2018
|
This bit me too. Here's my experience with this bug in case it helps anyone. My team used bower-away to migrate from bower to yarn, so all of our non-dev dependencies are under the @bower_components namespace. As we upgrade and add non-dev packages, we're trying to keep them all under @bower_components, for the sake of consistency. These are the steps I took... First try with the github repo and the namespace: The dist dir is missing due to this bug. Now try with the github repo, but without the @bower_components namespace... The dist dir is still missing, again due to this bug. Now try using package name, rather than github repo... The dist dir is now there. However, I want it to be under @bower_components, since that's where all my other non-dev deps reside, so this doesn't work for me. Try specifying package name instead of github repo, but using the namespace... Error! Why doesn't this syntax work??? Is there no way to specify a package name along with a namespace?? I ended up working around this by installing using the package name without the @bower_components namespace, and then grabbing the resolved URL from yarn.lock, and running yarn add again using that: This works, but is obviously less than ideal, and I wasted over an hour on it. Yarn maintainers, this bug has now been open for over 3 months. In addition, there are 7 related bugs, and 16 votes. Why has this not been addressed? |
|
Aliases are very experimental and we don't really recommend using them - even if they work, they break the expected semantics in various ways, especially with regard to peer dependencies. I would recommend you to find a way to use the packages from npm without using the
Mostly because I missed this issue, sorry @rtsao, you did a good investigation! Moving this logic to the base fetcher could work, yes. It would have to be called only in some cases though, since we don't want it to happen for regular tarballs (which are expected to already have been packed). |
|
Is this ever going to be addressed? I switch to Yarn because npm was falling behind on crucial features, but now it looks like the pendulum is swinging back again. This issue has been known in one ticket or another for probably 16 months now. Since at least version |
|
Yarn is a community project. If a feature is so problematic, we invite you to contribute to fix it. Right now nobody stepped in yet, and it isn't something we are facing ourselves, so it's lower priority for us than other fixes and features. Still, if you open a PR, we'll gladly review it 🙂 |
|
Totally understand if that's the holdup and don't get me wrong, I'm very thankful for the hard work! I would be happy to contribute when I find the time... Always the excuse I know.... My question was meant to be a, "Why isn't this a higher priority?" and not a "Why isn't this fixed dammit!?" Here's why I think this is a big issue: Github has a billion forks people definitely want to use as they would use a normal package. I avoid forking things quite a lot because I'm not sure if Can you possibly point me towards the part(s) of the codebase that manage invoking |
|
Lifecycle scripts are executed here, which is called through here and here.
Because no maintainer seem to have been suffering from this issue - it's not to say that the problem doesn't exist, but we all tend to work first on what affects us 🙂 We do try to fix problems other people report when we get the chance, but time is scarce and some help is always appreciated. |
|
Thanks very much @arcanis! I'll poke around in those files when I find some downtime and see if I can find a fix. |
gcampax
added a commit
to stanford-oval/genie-cloud
that referenced
this issue
Oct 5, 2018
yarn has a bug (<yarnpkg/yarn#5235>) where git dependencies are treated differently than github deps
markphilpot
added a commit
to CanopyIQ/rich-markdown-editor
that referenced
this issue
Oct 22, 2018
michaelsbradleyjr
added a commit
to embarklabs/embark
that referenced
this issue
Nov 25, 2018
** TL;DR ** These changes affect workflow with yarn. To prevent embark's 'prepare' script from running undesirably: - If node_modules is in place and you're reinstalling after switching branches: yarn run install_all - If node_modules is missing (fresh clone or deleted): EMBARK_NO_PREPARE=t yarn install && cd embark-ui && yarn install && cd .. It's not recommended to set EMBARK_NO_PREPARE in your environment (e.g. in '.bashrc') since that would interfere with embark's 'release' script if/when you run it. ----------------- 1. Specify embark's build-related steps in the 'prepare' script of package.json. When embark is installed directly from GitHub the 'prepare' script results in a "pre install" phase (handled automatically by npm/yarn) that fetches devDependencies, builds embark (including embark-ui), packs a tarball with the same steps (minus testing and tree-checking) as would happen during an embark release, and finally does a production install from that tarball. Important point: installs from GitHub must be performed with yarn; they're no longer possible with npm since during the "pre install" phase npm will honor embark's .npmrc and "engines" settings. The following will work correctly after this commit is merged: yarn add git+https://github.com/embark-framework/embark.git Use of "hosted git" shortcuts (e.g. 'embark-framework/embark#bracnh') won't work correctly because yarn doesn't fully support them: yarnpkg/yarn#5235 It's important to use 'git+https' urls. Following a succesful install with 'git+https' it is possible to use a "hosted git" shortcut or 'https' url, but that's owing to a subtle and unreliable interaction between yarn's cache and yarn's logic for installing from a url/shortcut. 2. Adjust the npm configs (.npmrc) for embark/-ui so that 'yarn run [cmd] [--opt]' can be used in place of 'npm run [cmd] -- [--opt]'. Either way is okay for running scripts, they're equivalent, but note the requirement to use '--' before specifying command options with 'npm run'. 3. Introduce yarn configs (.yarnrc) for embark/-ui and include the 'check-files' directive. H/t to @alaibe for the recommendation. 4. Ignore embark's 'dist/typings' and 'scripts' directories when packing a tarball. 5. Refactor embark/-ui's npm-scripts in relation to the 'prepare' script, and make other small improvements. Notably, if the environment variable EMBARK_NO_PREPARE is truthy (from JS perspective) then embark's 'prepare' script will exit early. This prevents 'install_all' and 'prepare' from getting stuck in a loop ('install:core' uses cross-env to set EMBARK_NO_PREPARE) and provides a mechanism for users to skip the 'prepare' script when doing a fresh install: EMBARK_NO_PREPARE=t yarn install 6. Give .js extensions to node scripts in embark's 'scripts/', remove the shebang lines, and have npm-scripts explicitly invoke them with node. This arrangement works for all platforms: Linux, macOS, and Windows. 7. Adjust travis and appveyor configs. Since at present there aren't any tests or other CI steps that make use of embark-ui's production build, set EMBARK_NO_PREPARE in the CI environments and invoke 'build:node' directly. Check the working tree after 'yarn install' for embark/-ui. This detects situations where changes should have been committed to yarn.lock but were not. Check the working tree again at the end to detect situations where ignore files should have been adjusted but were not. Both checks could also detect other surprising behavior that needs to be investigated. Any time the working tree is not clean (there are untracked files or changes) CI will fail. Drop CI runs for node 8.11.3 because that version uses an older npm that results in unstaged changes to the test apps' package-lock.json files, causing the working tree check to fail at the end of the CI run. A simple workaround isn't apparent, but the matter can be revisited. 8. Refactor embark's 'release' script in light of the 'prepare' script. Notably, do the push step only after 'npm publish' completes successfully. This allows embark's 'prepare' and 'prepublishOnly' scripts to detect problems before a commit and tag are pushed to GitHub, avoiding a need to rebase/revert the remote release branch; the local branch will still need to have a commit dropped and tag deleted before rerunning the 'release' script. Prompt the user if the 'release' script is not being run in '--dry-run' mode. Provide additional visual indicators of '--dry-run' mode. Force the user to supply '--repo-branch [branch]' if the intention is to release from a branch other than master.
michaelsbradleyjr
added a commit
to embarklabs/embark
that referenced
this issue
Nov 26, 2018
** TL;DR ** These changes affect workflow with yarn. To prevent embark's 'prepare' script from running undesirably: - If node_modules is in place and you're reinstalling after switching branches: yarn run install_all - If node_modules is missing (fresh clone or deleted): EMBARK_NO_PREPARE=t yarn install && cd embark-ui && yarn install && cd .. It's not recommended to set EMBARK_NO_PREPARE in your environment (e.g. in '.bashrc') since that would interfere with embark's 'release' script if/when you run it. ----------------- 1. Specify embark's build-related steps in the 'prepare' script of package.json. When embark is installed directly from GitHub the 'prepare' script results in a "pre install" phase (handled automatically by npm/yarn) that fetches devDependencies, builds embark (including embark-ui), packs a tarball with the same steps (minus testing and tree-checking) as would happen during an embark release, and finally does a production install from that tarball. Important point: installs from GitHub must be performed with yarn; they're no longer possible with npm since during the "pre install" phase npm will honor embark's .npmrc and "engines" settings. The following will work correctly after this commit is merged: yarn add git+https://github.com/embark-framework/embark.git Use of "hosted git" shortcuts (e.g. 'embark-framework/embark#bracnh') won't work correctly because yarn doesn't fully support them: yarnpkg/yarn#5235 It's important to use 'git+https' urls. Following a succesful install with 'git+https' it is possible to use a "hosted git" shortcut or 'https' url, but that's owing to a subtle and unreliable interaction between yarn's cache and yarn's logic for installing from a url/shortcut. 2. Adjust the npm configs (.npmrc) for embark/-ui so that 'yarn run [cmd] [--opt]' can be used in place of 'npm run [cmd] -- [--opt]'. Either way is okay for running scripts, they're equivalent, but note the requirement to use '--' before specifying command options with 'npm run'. 3. Introduce yarn configs (.yarnrc) for embark/-ui and include the 'check-files' directive. H/t to @alaibe for the recommendation. 4. Ignore embark's 'dist/typings' and 'scripts' directories when packing a tarball. 5. Refactor embark/-ui's npm-scripts in relation to the 'prepare' script, and make other small improvements. Notably, if the environment variable EMBARK_NO_PREPARE is truthy (from JS perspective) then embark's 'prepare' script will exit early. This prevents 'install_all' and 'prepare' from getting stuck in a loop ('install:core' uses cross-env to set EMBARK_NO_PREPARE) and provides a mechanism for users to skip the 'prepare' script when doing a fresh install: EMBARK_NO_PREPARE=t yarn install 6. Give .js extensions to node scripts in embark's 'scripts/', remove the shebang lines, and have npm-scripts explicitly invoke them with node. This arrangement works for all platforms: Linux, macOS, and Windows. 7. Adjust travis and appveyor configs. Since at present there aren't any tests or other CI steps that make use of embark-ui's production build, set EMBARK_NO_PREPARE in the CI environments and invoke 'build:node' directly. Check the working tree after 'yarn install' for embark/-ui. This detects situations where changes should have been committed to yarn.lock but were not. Check the working tree again at the end to detect situations where ignore files should have been adjusted but were not. Both checks could also detect other surprising behavior that needs to be investigated. Any time the working tree is not clean (there are untracked files or changes) CI will fail. Drop CI runs for node 8.11.3 because that version uses an older npm that results in unstaged changes to the test apps' package-lock.json files, causing the working tree check to fail at the end of the CI run. A simple workaround isn't apparent, but the matter can be revisited. 8. Refactor embark's 'release' script in light of the 'prepare' script. Notably, do the push step only after 'npm publish' completes successfully. This allows embark's 'prepare' and 'prepublishOnly' scripts to detect problems before a commit and tag are pushed to GitHub, avoiding a need to rebase/revert the remote release branch; the local branch will still need to have a commit dropped and tag deleted before rerunning the 'release' script. Prompt the user if the 'release' script is not being run in '--dry-run' mode. Provide additional visual indicators of '--dry-run' mode. Force the user to supply '--repo-branch [branch]' if the intention is to release from a branch other than master.
michaelsbradleyjr
added a commit
to embarklabs/embark
that referenced
this issue
Nov 26, 2018
** TL;DR ** These changes affect workflow with yarn. To prevent embark's 'prepare' script from running undesirably: - If node_modules is in place and you're reinstalling after switching branches: yarn run install_all - If node_modules is missing (fresh clone or deleted): EMBARK_NO_PREPARE=t yarn install && cd embark-ui && yarn install && cd .. It's not recommended to set EMBARK_NO_PREPARE in your environment (e.g. in '.bashrc') since that would interfere with embark's 'release' script if/when you run it. ----------------- 1. Specify embark's build-related steps in the 'prepare' script of package.json. When embark is installed directly from GitHub the 'prepare' script results in a "pre install" phase (handled automatically by npm/yarn) that fetches devDependencies, builds embark (including embark-ui), packs a tarball with the same steps (minus testing and tree-checking) as would happen during an embark release, and finally does a production install from that tarball. Important point: installs from GitHub must be performed with yarn; they're no longer possible with npm since during the "pre install" phase npm will honor embark's .npmrc and "engines" settings. The following will work correctly after this commit is merged: yarn add git+https://github.com/embark-framework/embark.git Use of "hosted git" shortcuts (e.g. 'embark-framework/embark#bracnh') won't work correctly because yarn doesn't fully support them: yarnpkg/yarn#5235 It's important to use 'git+https' urls. Following a succesful install with 'git+https' it is possible to use a "hosted git" shortcut or 'https' url, but that's owing to a subtle and unreliable interaction between yarn's cache and yarn's logic for installing from a url/shortcut. 2. Adjust the npm configs (.npmrc) for embark/-ui so that 'yarn run [cmd] [--opt]' can be used in place of 'npm run [cmd] -- [--opt]'. Either way is okay for running scripts, they're equivalent, but note the requirement to use '--' before specifying command options with 'npm run'. 3. Introduce yarn configs (.yarnrc) for embark/-ui and include the 'check-files' directive. H/t to @alaibe for the recommendation. 4. Ignore embark's 'dist/typings' and 'scripts' directories when packing a tarball. 5. Refactor embark/-ui's npm-scripts in relation to the 'prepare' script, and make other small improvements. Notably, if the environment variable EMBARK_NO_PREPARE is truthy (from JS perspective) then embark's 'prepare' script will exit early. This prevents 'install_all' and 'prepare' from getting stuck in a loop ('install:core' uses cross-env to set EMBARK_NO_PREPARE) and provides a mechanism for users to skip the 'prepare' script when doing a fresh install: EMBARK_NO_PREPARE=t yarn install 6. Give .js extensions to node scripts in embark's 'scripts/', remove the shebang lines, and have npm-scripts explicitly invoke them with node. This arrangement works for all platforms: Linux, macOS, and Windows. 7. Adjust travis and appveyor configs. Since at present there aren't any tests or other CI steps that make use of embark-ui's production build, set EMBARK_NO_PREPARE in the CI environments and invoke 'build:node' directly. Check the working tree after 'yarn install' for embark/-ui. This detects situations where changes should have been committed to yarn.lock but were not. Check the working tree again at the end to detect situations where ignore files should have been adjusted but were not. Both checks could also detect other surprising behavior that needs to be investigated. Any time the working tree is not clean (there are untracked files or changes) CI will fail. Drop CI runs for node 8.11.3 because that version uses an older npm that results in unstaged changes to the test apps' package-lock.json files, causing the working tree check to fail at the end of the CI run. A simple workaround isn't apparent, but the matter can be revisited. 8. Refactor embark's 'release' script in light of the 'prepare' script. Notably, do the push step only after 'npm publish' completes successfully. This allows embark's 'prepare' and 'prepublishOnly' scripts to detect problems before a commit and tag are pushed to GitHub, avoiding a need to rebase/revert the remote release branch; the local branch will still need to have a commit dropped and tag deleted before rerunning the 'release' script. Prompt the user if the 'release' script is not being run in '--dry-run' mode. Provide additional visual indicators of '--dry-run' mode. Force the user to supply '--repo-branch [branch]' if the intention is to release from a branch other than master.
ntf
added a commit
to ntf/lightweight-charts
that referenced
this issue
Aug 23, 2021
This file is being used in conjunction with the `prepare` script. See this for details: yarnpkg/yarn#5235 (comment)
|
@arcanis I don't see |
According to the Yarn Rulebook Yarn 2 uses |
Prepack is not the same. They’re run at different times. Prepack is run before packing. Not after installing unlike prepare. |
Yes, in npm But in Yarn 2 |
jd-gray
added a commit
to trainual/react-orgchart
that referenced
this issue
Oct 13, 2021
…cuted and artifcats generated From: yarnpkg/yarn#5235 (comment)
|
Any workarounds for v1 users? |
Floozutter
added a commit
to EmotionCognitionLab/pvs-breath-pacer
that referenced
this issue
Mar 18, 2022
so that the results of the prepare script are kept for Yarn users https://stackoverflow.com/a/61760051 yarnpkg/yarn#5235
chochihim
pushed a commit
to chochihim/react-native-track-player
that referenced
this issue
May 29, 2022
Ldoppea
added a commit
to cozy/react-native-webview
that referenced
this issue
Aug 17, 2022
To use this lib in our project we will `yarn build` and commit `/lib` content This will allow us to add this lib in the `package.json` by using the Github URL We cannot use the `prepare` entry from `package.json` due to a bug when using Github as source with yarn 1.x (cf yarnpkg/yarn/issues/5235)
Ldoppea
added a commit
to cozy/react-native-webview
that referenced
this issue
Aug 17, 2022
To use this lib in our project we will `yarn build` and commit `/lib` content This will allow us to add this lib in the `package.json` by using the Github URL We cannot use the `prepare` entry from `package.json` due to a bug when using Github as source with yarn 1.x (cf yarnpkg/yarn#5235)
Ldoppea
added a commit
to cozy/react-native-webview
that referenced
this issue
Aug 17, 2022
To use this lib in our project we will `yarn build` and commit `/lib` content This will allow us to add this lib in the `package.json` by using the Github URL We cannot use the `prepare` entry from `package.json` due to a bug when using Github as source with yarn 1.x (cf yarnpkg/yarn#5235)
Ldoppea
added a commit
to cozy/react-native-webview
that referenced
this issue
Aug 26, 2022
To use this lib in our project we will `yarn build` and commit `/lib` content This will allow us to add this lib in the `package.json` by using the Github URL We cannot use the `prepare` entry from `package.json` due to a bug when using Github as source with yarn 1.x (cf yarnpkg/yarn#5235)
chochihim
pushed a commit
to chochihim/react-native-track-player
that referenced
this issue
Nov 16, 2022
stonesthatwhisper
added a commit
to stonesthatwhisper/react-pdf
that referenced
this issue
Nov 17, 2022
davidisaaclee
added a commit
to davidisaaclee/capacitor-plugins
that referenced
this issue
Apr 15, 2023
Ldoppea
added a commit
to cozy/react-native-bootsplash
that referenced
this issue
Aug 3, 2023
To use this lib in our project we will `yarn prepare` and commit `/dist` content This will allow us to add this lib in the `package.json` by using the Github URL We cannot use the `prepare` entry from `package.json` to install it from the consumer project due to a bug when using Github as source with yarn 1.x (cf yarnpkg/yarn#5235)
Ldoppea
added a commit
to cozy/react-native-bootsplash
that referenced
this issue
Aug 3, 2023
To use this lib in our project we will `yarn prepare` and commit `/dist` content This will allow us to add this lib in the `package.json` by using the Github URL We cannot use the `prepare` entry from `package.json` to install it from the consumer project due to a bug when using Github as source with yarn 1.x (cf yarnpkg/yarn#5235)
illetid
added a commit
to tradingview/lightweight-charts
that referenced
this issue
May 8, 2024
* fix pane widget and separator feature previously implemented in 22c6b03 * Add prepare scripts to package.json * Add empty .npmignore This file is being used in conjunction with the `prepare` script. See this for details: yarnpkg/yarn#5235 (comment) * implement subscribePaneResize and unsubscribePaneResize * add ChartApi#removePane and ChartApi#swapPane, update Series#applyOptions for pane option * update .size-limit.js * Update package.json * Revert "implement subscribePaneResize and unsubscribePaneResize" This reverts commit 2194ebc * add ChartApi#getPaneElements() * fix pane widget and separator feature previously implemented in 22c6b03 * implement subscribePaneResize and unsubscribePaneResize * add ChartApi#removePane and ChartApi#swapPane, update Series#applyOptions for pane option * Revert "implement subscribePaneResize and unsubscribePaneResize" This reverts commit 2194ebc * add ChartApi#getPaneElements() * update .size-limit.js and linter errors * add paneIndex to MouseEventParams (click and crosshair event) * add nonPrimaryPriceScale to ChartOptions for non primary pane * fix: resize panes * fix: remove empty panes * fix: be able to move series to 0 index pane * fix: paneSize method receive paneIndex * chore: add method description * update size limit * add basic e2e tests * add coverage tests * add coverage test * add customisable options * improve coverage * add PaneApi * add paneApi coverage test * remove dedicated pane options * rename method * remove pane index mapping * remove paneIndex from series options * fix tests * fix line series * remove PaneInfo interface * remove paneIndex from Series * cleanup removePane and swapPane * fix crosshair horizontal line on all panes * fix prevent removing last pane * fix: remove non-primary price scale * cleanup * Pane separator & panes resize improvements * fix add jsdoc comment * fix: rename details to point * remove getPaneElements api * add CrosshairMarksPaneView per pane * cleanup tests * fix invalidation * fix CrosshairMarksPaneView order * add getSeriesByPane and getPaneBySeries apis * add series method to pane * update size limit * createSeries fix * add PaneApi getHTMLElement + change getSeriesByPane * rename method * add integration tests * fix: remove methods from ChartApi * Update src/api/iseries-api.ts Co-authored-by: Mark Silverwood <msilverwood@gmail.com> * Update src/model/chart-model.ts Co-authored-by: Mark Silverwood <msilverwood@gmail.com> * fixed code review suggestions * move method to private * Update src/api/ichart-api.ts Co-authored-by: Mark Silverwood <msilverwood@gmail.com> * fix paneIndex types * change iseries-api description * add how to guide * add sidebar page * add documentation links * fix multiple logos * add e2e tests * add docs suggestions * fix links * fix docs links * Update website/tutorials/how_to/panes.mdx Co-authored-by: Evgeniia Riazanova <eugeniyaryazanova@gmail.com> * update docs * fix markdown formatting * add tm signs * fix typo * rename createPane method * make getOrCreatePane private * _getOrCreatePane refactoring * fix: series priceScaleId option * fix: add target blank to attr-logo * test: disable attribution logo on unrelated tests --------- Co-authored-by: Adrian Ng <ntf123@gmail.com> Co-authored-by: Kirill Chetverikov <kchetverikov@tradingview.com> Co-authored-by: Mark Silverwood <msilverwood@gmail.com> Co-authored-by: Evgeniia Riazanova <eugeniyaryazanova@gmail.com>
SlicedSilver
added a commit
to tradingview/lightweight-charts
that referenced
this issue
May 8, 2024
* fix pane widget and separator feature previously implemented in 22c6b03 * Add prepare scripts to package.json * Add empty .npmignore This file is being used in conjunction with the `prepare` script. See this for details: yarnpkg/yarn#5235 (comment) * implement subscribePaneResize and unsubscribePaneResize * add ChartApi#removePane and ChartApi#swapPane, update Series#applyOptions for pane option * update .size-limit.js * Update package.json * Revert "implement subscribePaneResize and unsubscribePaneResize" This reverts commit 2194ebc * add ChartApi#getPaneElements() * fix pane widget and separator feature previously implemented in 22c6b03 * implement subscribePaneResize and unsubscribePaneResize * add ChartApi#removePane and ChartApi#swapPane, update Series#applyOptions for pane option * Revert "implement subscribePaneResize and unsubscribePaneResize" This reverts commit 2194ebc * add ChartApi#getPaneElements() * update .size-limit.js and linter errors * add paneIndex to MouseEventParams (click and crosshair event) * add nonPrimaryPriceScale to ChartOptions for non primary pane * fix: resize panes * fix: remove empty panes * fix: be able to move series to 0 index pane * fix: paneSize method receive paneIndex * chore: add method description * update size limit * add basic e2e tests * add coverage tests * add coverage test * add customisable options * improve coverage * add PaneApi * add paneApi coverage test * remove dedicated pane options * rename method * remove pane index mapping * remove paneIndex from series options * fix tests * fix line series * remove PaneInfo interface * remove paneIndex from Series * cleanup removePane and swapPane * fix crosshair horizontal line on all panes * fix prevent removing last pane * fix: remove non-primary price scale * cleanup * Pane separator & panes resize improvements * fix add jsdoc comment * fix: rename details to point * remove getPaneElements api * add CrosshairMarksPaneView per pane * cleanup tests * fix invalidation * fix CrosshairMarksPaneView order * add getSeriesByPane and getPaneBySeries apis * add series method to pane * update size limit * createSeries fix * add PaneApi getHTMLElement + change getSeriesByPane * rename method * add integration tests * fix: remove methods from ChartApi * Update src/api/iseries-api.ts Co-authored-by: Mark Silverwood <msilverwood@gmail.com> * Update src/model/chart-model.ts Co-authored-by: Mark Silverwood <msilverwood@gmail.com> * fixed code review suggestions * move method to private * Update src/api/ichart-api.ts Co-authored-by: Mark Silverwood <msilverwood@gmail.com> * fix paneIndex types * change iseries-api description * add how to guide * add sidebar page * add documentation links * fix multiple logos * add e2e tests * add docs suggestions * fix links * fix docs links * Update website/tutorials/how_to/panes.mdx Co-authored-by: Evgeniia Riazanova <eugeniyaryazanova@gmail.com> * update docs * fix markdown formatting * add tm signs * fix typo * rename createPane method * make getOrCreatePane private * _getOrCreatePane refactoring * fix: series priceScaleId option * fix: add target blank to attr-logo * test: disable attribution logo on unrelated tests --------- Co-authored-by: Adrian Ng <ntf123@gmail.com> Co-authored-by: Kirill Chetverikov <kchetverikov@tradingview.com> Co-authored-by: Mark Silverwood <msilverwood@gmail.com> Co-authored-by: Evgeniia Riazanova <eugeniyaryazanova@gmail.com>
jessealama
added a commit
to jessealama/ecmarkup
that referenced
this issue
May 23, 2024
Related: yarnpkg/yarn#5235
nss213
added a commit
to LearnToBeFoundation/perseus
that referenced
this issue
Jul 9, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
Do you want to request a feature or report a bug?
Bug
What is the current behavior?
When a hosted git dependency is installed, lifecycle scripts are not run (e.g.
prepare)If the current behavior is a bug, please provide the steps to reproduce.
Run
yarn add user/repooryarn add github:user/repo. No lifecycle scripts will be run.What is the expected behavior?
prepareshould be run on install (like with npm@5)Please mention your node.js, yarn and operating system version.
Node.js 9.4.0
Yarn 1.3.2
MacOS 10.13
I've done some investigation as to why this broken. This is what I've found:
#3553 added the correct behavior, but only for git fetching, meaning the dependency was actually fetched via git.
Because Yarn recognizes certain git hosts, Yarn will install these dependencies via HTTP/tarball method instead of git (presumably for performance). So if this logic is triggered (which will happen with dependencies formatted like
repo/userorgithub:repo/user, then the appropriate lifecycle scripts won't be run.Related issues:
prepackwhen installing Git dependencies #5047I'd be interested in making a PR to resolve this, but figured I'd make an issue first. I'm thinking that the logic for running lifecycle scripts in
src/fetchers/git-fetcher.jsshould probably be moved into the more genericsrc/fetchers/base-fetcher, since per #3911 lifecycle scripts should be run for non-git dependencies as well.The text was updated successfully, but these errors were encountered: