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

enable building from source: use a single lockfile per package. #870

Closed
happysalada opened this issue Oct 17, 2023 · 11 comments
Closed

enable building from source: use a single lockfile per package. #870

happysalada opened this issue Oct 17, 2023 · 11 comments

Comments

@happysalada
Copy link
Contributor

What version of VS Code are you using?

not using vscode

What version of Tailwind CSS IntelliSense are you using?

0.10.1

What version of Tailwind CSS are you using?

latest

What package manager are you using?

npm

What operating system are you using?

macos or linux

Tailwind config

N/A

VS Code settings
N/A

Reproduction URL

A public GitHub repo that includes a minimal reproduction of the bug. Please do not link to your actual project, what we need instead is a minimal reproduction in a fresh project without any unnecessary code. This means it doesn't matter if your real project is private/confidential, since we want a link to a separate, isolated reproduction anyways.

Describe your issue

The repo currently has two lockfiles for each package. There is the global lockfile that contains esbuild, and a local lockfile that contains the rest of the dependencies.
That means that each package cannot be built separately. (if you try it will complain about a missing esbuild module).
It would help with building from source if each of the package lockfiles contained esbuild so that they could be built standalone.
So that in each package directory you could just run npm install and npm run build.

For context, I'm trying to package the tailwind-language-server binary for nixos.
The binary can be used with any editors that is not vscode (neovim, helix...).

@thecrypticace let me know if it's not possible, I completely understand.

@thecrypticace
Copy link
Contributor

Thanks for opening this. As far as I know this shouldn't be a major issue. I'm going to take a look at this, swapping out Lerna with proper workspaces — which might help with that, and some other things for a future update. Hopefully some of it I can do sooner rather than later

@happysalada
Copy link
Contributor Author

Yes workspaces with a single lockfile would be ideal.

Thanks a lot for taking a look at this and being so responsive !

@thecrypticace
Copy link
Contributor

@happysalada I've got a branch that swaps out Lerna for workspaces and has a handful of other upgrades. I'm not done but it's a start.

Mind taking a look at feat/cleanups and letting me know if that setup is workable?

@happysalada
Copy link
Contributor Author

it's a nice improvement.
I'm still getting an error

> Executing npmBuildHook
       > npm ERR! No workspaces found:
       > npm ERR!   --workspace=packages/tailwdincss-language-server

could it be because the top package.json has private: true ?
I think the child packages should have that, but not the top one. Not 100% sure.

@thecrypticace
Copy link
Contributor

That's because you've got a typo :)

npm run build --workspace=packages/tailwindcss-language-server

@happysalada
Copy link
Contributor Author

Indeed without the typo it works much better!

Ive got one last question.
There are releases for the whole repo and versions for each packages separately.
Should the package source be updated anything the repo receives a versiom bump ?
Or only when the actual package changes version ?

@thecrypticace
Copy link
Contributor

thecrypticace commented Oct 19, 2023

Releases on GitHub generally correspond to the VSCode extension under packages/vscode-tailwindcss.

We publish and version the language server and language service separately on NPM but we don't currently publish GH releases whenever any update happens. Only when the version of the corresponding package changes. We may change this in the future but for now we're going to keep that as is.

@happysalada
Copy link
Contributor Author

Sounds good, ill just use the gh releases as the version for the language server for now just because its more convenient. Let me know if that changes in the future.

Im ready to contribute this to nixos whenever the next release for the repo comes.

Thanks a lot for being super responsive and helpful !

@thecrypticace
Copy link
Contributor

Of course, thanks for helping look into this!

@happysalada
Copy link
Contributor Author

happysalada commented Oct 20, 2023

Just to know, do you have a release planned in mind with the changes ?
(No worries if not)

@thecrypticace
Copy link
Contributor

Sometime next week probably. Gonna get a pre-release version out today though to test that everything still builds and runs fine in GH actions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants