Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved support for lerna / yarn workspaces #1466

Closed
JMS-1 opened this issue May 14, 2020 · 1 comment
Closed

Improved support for lerna / yarn workspaces #1466

JMS-1 opened this issue May 14, 2020 · 1 comment
Labels
type/build Anything related to the build process type/feat Any feature requests or improvements
Milestone

Comments

@JMS-1
Copy link

JMS-1 commented May 14, 2020

Feature Request

We are using fomantic-ui 2.8.4 in a lerna/yarn environment. The build process in a subfolder fails because it is not able to find the semantic.json configuration and falls back to some default - which in our case is of no help since our semantic.json is customized.

The reason is that in the user.js task require-dot-file ist called with only the single parameter "semantic.json". In this case require-dot-file will start looking up for the indicated file starting at its very own location in the lerna global node_modules which is wrong - in a single file structure with a single project in a folder this happens to be correct.

There is an ugly workaround using the nohoist feature of lerna/yarn workspaces. I think a far more better solution would be to add process.cwd() as a second parameter to the require-dot-file call in the user.js task. In fact this may be a more consistent and defensice programming style than rely on some starting folder randomly choosen by some external (to fomantic-ui) code.

I can't estimate the importance of this issue and but since I found no other report using lerna/yarn workspaces may be rare. But especially in combination of an application development in parallel to some library the concept is quite helpful. For example in our case we have a couple of applications using a common theming which has been outsourced to a separate npm module.

@JMS-1 JMS-1 added state/awaiting-triage Any issues or pull requests which haven't yet been triaged type/feat Any feature requests or improvements labels May 14, 2020
@lubber-de
Copy link
Member

Seems legit. I put your suggestion into PR #1467

@lubber-de lubber-de added this to the 2.8.x milestone May 14, 2020
@lubber-de lubber-de added state/has-pr An issue which has a related PR open type/build Anything related to the build process and removed state/awaiting-triage Any issues or pull requests which haven't yet been triaged labels May 14, 2020
@lubber-de lubber-de modified the milestones: 2.8.x, 2.8.5 May 19, 2020
@lubber-de lubber-de added tag/next-release/nightly Any issue which has a corresponding PR which has been merged and is available in the nightly build and removed state/has-pr An issue which has a related PR open labels May 23, 2020
@y0hami y0hami removed the tag/next-release/nightly Any issue which has a corresponding PR which has been merged and is available in the nightly build label Jun 1, 2020
@y0hami y0hami closed this as completed Jun 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/build Anything related to the build process type/feat Any feature requests or improvements
Projects
None yet
Development

No branches or pull requests

3 participants