Move bulma-css-variables to @bulvar/bulma #1876

Open
opened 2021-11-22 21:50:25 +00:00 by konrad · 17 comments
Owner

From the matrix chat:

adrinux: Seen the merge! Unfortunately any joy is tempered by the fact I also had an email from Daniil Chudo who maintains bulma-css-variables saying it was deprecated! Bah!

And to 'Please check out @bulvar' https://github.com/daniil4udo/bulvar/tree/v0.9.3
A repo that is 4 days old and had it's first release today. I guess my first email to him about the missing comma's prompted a public release of something he'd been working on for a while.

kolaente: hahaha well

adrinux: I don't know that it changes much - I presume the variable names will be identical and we can swap bulma-css-variables for bulvar without breaking anything, but it's obviously less confidence inspiring.

From the matrix chat: > adrinux: Seen the merge! Unfortunately any joy is tempered by the fact I also had an email from Daniil Chudo who maintains bulma-css-variables saying it was deprecated! Bah! > > And to 'Please check out @bulvar' https://github.com/daniil4udo/bulvar/tree/v0.9.3 > A repo that is 4 days old and had it's first release today. I guess my first email to him about the missing comma's prompted a public release of something he'd been working on for a while. > kolaente: hahaha well > adrinux: I don't know that it changes much - I presume the variable names will be identical and we can swap bulma-css-variables for bulvar without breaking anything, but it's obviously less confidence inspiring.
konrad added the
area/internal-code
label 2021-11-22 21:51:02 +00:00
Member

@bulvar/bulma looks really nice!

Not sure if it makes sense to priorize this though.

Since our target with moving to bulma-css-variables was mostly to support dark mode and this works now I think we should focus on stuff like finishing the move to vue 3, scoping the styles etc.

Thinking here in the same way as you comment from here:

I agree the current frontend could use improvement. In the long-term I'd like to refactor that, maybe even moving away from bulma entierly. Having everything scoped in components would probably help with that. That would be a whole heap of work with little short term benefit - It would make it more maintainable in the long-term though. I don't see it happening anytime soon so I think we should focus on improving what we currently have. That includes moving more styles to components and using bulm-css-variables. Thoughts?

Also it might make scoping more difficult for now since @bulvar/bulma seems not to support SCSS or at least partly imports. I did not get from the repo why that is the case, seems like they simply bundle the SCSS.

EDIT: Maybe I misunderstood this:

CSS ONLY
IMPORTANT: This packages is CSS ONLY!

@bulvar/bulma looks really nice! Not sure if it makes sense to priorize this though. Since our target with moving to bulma-css-variables was mostly to support dark mode and this works now I think we should focus on stuff like finishing the move to vue 3, scoping the styles etc. Thinking here in the same way as you comment [from here](https://kolaente.dev/vikunja/frontend/issues/756#issuecomment-16104): > I agree the current frontend could use improvement. In the long-term I'd like to refactor that, maybe even moving away from bulma entierly. Having everything scoped in components would probably help with that. That would be a whole heap of work with little short term benefit - It would make it more maintainable in the long-term though. I don't see it happening anytime soon so I think we should focus on improving what we currently have. That includes moving more styles to components and using bulm-css-variables. Thoughts? Also it might make scoping more difficult for now since @bulvar/bulma seems not to support SCSS or at least partly imports. I did not get from the repo why that is the case, seems like they simply bundle the SCSS. **EDIT:** Maybe I misunderstood [this](https://github.com/daniil4udo/bulvar/tree/v0.9.3/packages/bulma#%EF%B8%8F-css-only): > CSS ONLY IMPORTANT: This packages is CSS ONLY!
Author
Owner

Yup, agreed that this doesn't have a very high priority right now. We should do it in the too far away future if they plan on deprecating bulma-css-variables further.

Yup, agreed that this doesn't have a very high priority right now. We should do it in the too far away future if they plan on deprecating bulma-css-variables further.

CSS ONLY
IMPORTANT: This packages is CSS ONLY!

From digging about in the repo it looks like @bulvar/buefy is very much CSS only. All of Bulma's Sass files still seem to be present in @bulvar/bulma. So I tried swapping.

I can't figure out how to get sass imports to work with monorepo modules. This doesn't work:

@import "@bulvar/bulma/sass/utilities/_all";

From reading around it might need yet another npm module.
So I'll leave this branch https://kolaente.dev/adrinux/frontend/src/branch/bulvar-test but am not putting in any more effort to this.

> > CSS ONLY > IMPORTANT: This packages is CSS ONLY! From digging about in the repo it looks like @bulvar/buefy is very much CSS only. All of Bulma's Sass files still seem to be present in @bulvar/bulma. So I tried swapping. I can't figure out how to get sass imports to work with monorepo modules. This doesn't work: ``` @import "@bulvar/bulma/sass/utilities/_all"; ``` From reading around it might need yet another npm module. So I'll leave this branch https://kolaente.dev/adrinux/frontend/src/branch/bulvar-test but am not putting in any more effort to this.
Member
I think I found the issue: https://github.com/daniil4udo/bulvar/pull/33
Member

@adrinux The pull request got merged. Maybe you can try again if it works now.

If I saw it correctly you also need to add imports to the stuff in that shared folder.

@adrinux The pull request got merged. Maybe you can try again if it works now. If I saw it correctly you also need to add imports to the stuff in that shared folder.
Author
Owner

Is there a release with the fix yet?

Is there a release with the fix yet?
Member
I [asked for it](https://github.com/daniil4udo/bulvar/pull/33#issuecomment-979965917)
Member
Is released: https://github.com/daniil4udo/bulvar/releases/tag/v0.9.4
Member

Possible solution for this issue: vikunja/frontend#1074 (comment)

Possible solution for this issue: https://kolaente.dev/vikunja/frontend/issues/1074#issuecomment-20490
Member

@adrinux: do you want to update your bulvar branch to try this pull request: https://github.com/daniil4udo/bulvar/pull/42

@adrinux: do you want to update your bulvar branch to try this pull request: https://github.com/daniil4udo/bulvar/pull/42

@adrinux: do you want to update your bulvar branch to try this pull request: https://github.com/daniil4udo/bulvar/pull/42

I've no idea how to properly test a pull request on a released npm module...but I did a crude test - checked out that pull request and replaced @bulva/bulma with it in my node_modules folder.

The errors remain the same as from my previous comment a week ago, and for current bulvar release, example:

[vite-plugin-pwa] Can't find stylesheet to import.
   ╷
14 │ @use "@bulvar/bulma/sass/utilities/_all";
   │ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   ╵
  src/styles/common-imports.scss 14:1  @import
  src/App.vue 2:9                      root stylesheet

As I understand it the (sass?) path parser can't handle the @ used in monorepo modules. What's needed is another js module to handle those...but there seemed to be several options and no clear obvious winner.

But this is straying out of my expertise - I'm not even sure if I've diagnosed the problem correctly never mind the solution :)

This inability to actually read the sass files in @bulvar/bulma needs resolved before we can test with switching to @use helps with othe issues.

(On a tangent - does this mean all the sass @import in vikunja's styles need switched to @use too?).

> @adrinux: do you want to update your bulvar branch to try this pull request: https://github.com/daniil4udo/bulvar/pull/42 I've no idea how to properly test a pull request on a released npm module...but I did a crude test - checked out that pull request and replaced @bulva/bulma with it in my node_modules folder. The errors remain the same as from my previous comment a week ago, and for current bulvar release, example: ``` [vite-plugin-pwa] Can't find stylesheet to import. ╷ 14 │ @use "@bulvar/bulma/sass/utilities/_all"; │ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ╵ src/styles/common-imports.scss 14:1 @import src/App.vue 2:9 root stylesheet ``` As I understand it the (sass?) path parser can't handle the @ used in monorepo modules. What's needed is another js module to handle those...but there seemed to be several options and no clear obvious winner. But this is straying out of my expertise - I'm not even sure if I've diagnosed the problem correctly never mind the solution :) This inability to actually read the sass files in @bulvar/bulma needs resolved before we can test with switching to @use helps with othe issues. (On a tangent - does this mean all the sass @import in vikunja's styles need switched to @use too?).
Member

You can reference git / github urls.

@use "@bulvar/bulma/sass/utilities/_all";

The _all files were replaced with index files so you can reference the folder.

As I understand it the (sass?) path parser can't handle the @ used in monorepo modules.

You can simply reference relative to the node_modules folder. In combination with the index.sass files that should result in something like:

@use "../../node_modules/@bulvar/bulma/sass/utilities";

(On a tangent - does this mean all the sass @import in vikunja's styles need switched to @use too?).

No, but would be nice =)

You can [reference git / github urls](https://docs.npmjs.com/cli/v8/configuring-npm/package-json#git-urls-as-dependencies). > @use "@bulvar/bulma/sass/utilities/_all"; The `_all` files were replaced with `index` files so you can reference the folder. > As I understand it the (sass?) path parser can't handle the @ used in monorepo modules. You can simply reference relative to the node_modules folder. In combination with the `index.sass` files that should result in something like: `@use "../../node_modules/@bulvar/bulma/sass/utilities";` > (On a tangent - does this mean all the sass @import in vikunja's styles need switched to @use too?). No, but would be nice =)
Member

But this is straying out of my expertise - I'm not even sure if I've diagnosed the problem correctly never mind the solution :)

I'm also not sure. But it solves some of our problems. Might help to isolate the rest of the issues =)

> But this is straying out of my expertise - I'm not even sure if I've diagnosed the problem correctly never mind the solution :) I'm also not sure. But it solves *some* of our problems. Might help to isolate the rest of the issues =)

You can reference git / github urls.

In theory yes. Also with yarn add, in theory. I've read docs, I've read blogs, I've read issues. Can't get it to work. Almost...but just no.

@adrinux: do you want to update your bulvar branch to try this pull request: https://github.com/daniil4udo/bulvar/pull/42

In retrospect, 'no'. Too much of a time sync already to no productive use.

> You can [reference git / github urls](https://docs.npmjs.com/cli/v8/configuring-npm/package-json#git-urls-as-dependencies). In theory yes. Also with yarn add, in theory. I've read docs, I've read blogs, I've read issues. Can't get it to work. Almost...but just no. > @adrinux: do you want to update your bulvar branch to try this pull request: https://github.com/daniil4udo/bulvar/pull/42 In retrospect, 'no'. Too much of a time sync already to no productive use.
Member

You can reference git / github urls.

In theory yes. Also with yarn add, in theory. I've read docs, I've read blogs, I've read issues. Can't get it to work. Almost...but just no.

@adrinux: do you want to update your bulvar branch to try this pull request: https://github.com/daniil4udo/bulvar/pull/42

In retrospect, 'no'. Too much of a time sync already to no productive use.

Tried it myself, but also ran into issues. So I asked the author again: https://github.com/daniil4udo/bulvar/issues/38#issuecomment-985515227

> > You can [reference git / github urls](https://docs.npmjs.com/cli/v8/configuring-npm/package-json#git-urls-as-dependencies). > > In theory yes. Also with yarn add, in theory. I've read docs, I've read blogs, I've read issues. Can't get it to work. Almost...but just no. > > > > @adrinux: do you want to update your bulvar branch to try this pull request: https://github.com/daniil4udo/bulvar/pull/42 > > In retrospect, 'no'. Too much of a time sync already to no productive use. Tried it myself, but also ran into issues. So I asked the author again: https://github.com/daniil4udo/bulvar/issues/38#issuecomment-985515227

Tried it myself, but also ran into issues.

Thanks for giving it a shot - your failure makes me feel better about my failure :)
Shame though.

I'd have another go at just cloning it elsewhere and copying into node_modules to test it but I've been too busy this week.

> Tried it myself, but also ran into issues. Thanks for giving it a shot - your failure makes me feel better about my failure :) Shame though. I'd have another go at just cloning it elsewhere and copying into node_modules to test it but I've been too busy this week.
Member

Yeah I did something similar but had problems even then, because the author of bulvar uses Sass load path and I couldn't figure out how to adjust this in vite.

Then I changed the imports from @use "utilities[...] to @use "../utilites[...]`.

That makes it build but I have still probs with the result..

Yeah I did something similar but had problems even then, because the author of bulvar uses [Sass load path](https://sass-lang.com/documentation/cli/dart-sass#load-path) and I couldn't figure out how to adjust this in vite. Then I changed the imports from `@use "utilities[...]` to @use "../utilites[...]`. That makes it build but I have still probs with the result..
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: vikunja/vikunja#1876
No description provided.