grapesjs: BUG: Latest version 0.21.6 doesn't come with src folder

@bgrand-ch I think what you’re mentioning is fixable with CSS variables.

I was also thinking about introducing a new small module for theming, that would allow updating the editor appearance programmatically, and under the hood, it would be a matter of updating internal CSS variables.

it was just one file

@import "./editor_variables";
@import "./editor_vendor";
@import "./editor_fonts";
@import "./editor_icons";
@import "./custom";
@import "./custom/main";
@import './loader';

scss files are more organized and more powerful that css files but i have a backup plan

because of sass files to overwrite variables it is very important

Solution

clone the repository and run npm i grapesjs@latest create a bash function to do this at the same time in .bash_aliases something like this:

#!/bin/bash

# rename function to update_grapesjs or update_pkg if u want
update_grapesjs() {
    # Check if required arguments are provided
    if [ $# -lt 2 ]; then
        echo "Usage: update_grapesjs <package_directory> <repo_directory> [package_version]"
        return 1
    fi

    package_dir="$1"
    repo_dir="$2"
    package_version="${3:-latest}"

    # Change to the package directory
    cd "$package_dir" || return 1

    # Update the npm package to the specified version or latest
     npm install --save "grapesjs@$package_version"

    # Change to the repo directory
    cd "$repo_dir" || return 1

    # Clone the Git repository
    git clone https://github.com/GrapesJS/grapesjs.git .
}

# Usage:
# update_grapesjs <package_directory> <repo_directory> [package_version]
# Example 1: update_grapesjs "/path/to/package" "/path/to/repo" "1.2.3"
# Example 2: update_grapesjs "/path/to/package" "/path/to/repo"

extra work, but we used to it.

AFAIK, many packages seem to include the sources when published with NPM.

Sure, grapesjs was one of those, but that doesn’t mean it’s the right approach indeed there are many reasons not to do that. We’d like to be free to restructure/refactor the files and use the appropriate tech stack inside the source without breaking stuff for consumers like it’s happening now (eg. now we’re relying on TS, who knows what is coming next, same for SASS).

In the case of styles, the purpose of SASS default values is precisely to be able to customize the library’s styles.

As long as we use SASS, you’re free to build from the source but not from the distributed package.

I think that requiring to override every occurrence of a property in the CSS means that GrapesJS becomes as easy to theme as any other web app that don’t use SCSS or CSS variables.

There is a lot of stuff not even covered by the SASS variable so you’ll end up using CSS anyway with more important customizations. You can also notice from the CSS theming example that updating simple stuff like a color palette is not that different from variables as those are purely atomic class utilities. If there are other atomic classes that could be helpful, I’ll be happy to add them… and I’ll be definitely open to introducing CSS custom properties.

I hope you will reconsider including the SCSS files in the package

I published a new release with src/styles folder as a temporary patch but removed already the old recommendation of using SASS for theming. So I highly suggest avoiding relying on SASS variables as soon as you can as I’m planning to remove them again in the next v0.22.* release. If anybody wants to improve this part with more utility classes or CSS variables, PRs are always welcome.

Huge thanks to @quentin-bettoum for his PR https://github.com/GrapesJS/grapesjs/pull/5437

Thanks for your answer and for the release.

If anybody wants to improve this part with more utility classes or CSS variables, PRs are always welcome.

At some point, I will take a look at what I can do regarding CSS variables.

The source is useless in a distributed package, if that was the case I would need to release a new breaking change every time I decide to rename or move a file, so I’m not sure why you were relying on it in the first place.

AFAIK, many packages seem to include the sources when published with NPM.

In the case of styles, the purpose of SASS default values is precisely to be able to customize the library’s styles. I think that requiring to override every occurrence of a property in the CSS means that GrapesJS becomes as easy to theme as any other web app that don’t use SCSS or CSS variables.

I hope you will reconsider including the SCSS files in the package or, if you plan to change from SASS to something else as suggested above, to add CSS variables. Otherwise, the least annoying solution I’ll have in my case might be to manually copy the SCSS files and update them after each upgrade of GrapesJS. This is inconvenient, but still easier to maintain than CSS overrides, in my opinion.