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

[joukhar]

GrapesJS version

• I confirm to use the latest version of GrapesJS

What browser are you using?

Chrome Version 114.0.5735.199 (Official Build) (64-bit)

Reproducible demo link

N/A

Describe the bug

Latest version 0.21.6 doesn't come with src folder
when installing grapesjs using npm
npm install grapesjs@0.21.6

Code of Conduct

• I agree to follow this project's Code of Conduct

[artf]

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.

[joukhar]

because of sass files to overwrite variables it is very important

[artf]

I think you should be able to update CSS styles without relying on our internal tech choices for styling which might eventually change in the future (my bad for suggesting that in the first place).

Can you show me the exact variables you're trying to overwrite?

[joukhar]

/* Class names prefixes */

$app-prefix: 'bbb-' !default;
$nv-prefix : $app-prefix !default;
$rte-prefix: $app-prefix+'rte-' !default;
$mdl-prefix: $app-prefix+'mdl-' !default;
$am-prefix : $app-prefix+'am-' !default;
$cm-prefix : $app-prefix+'cm-' !default;
$pn-prefix : $app-prefix+'pn-' !default;
$com-prefix: $app-prefix+'com-' !default;
$sm-prefix : $app-prefix+'sm-' !default;
$cv-prefix : $app-prefix+'cv-' !default;
$clm-prefix: $app-prefix+'clm-' !default;
$trt-prefix: $app-prefix+'trt-' !default;
$cui-cls   : $app-prefix+'cui' !default;

/*
  New Pattern Color System
  With this should be easier to overwrite colors
  not only in SCSS but even CSS
*/
$primaryColor   : #192132 !default;
$secondaryColor : #ebf7ff !default;
$tertiaryColor  : #0084e2 !default;
$quaternaryColor: #0095ff !default;

/* Dark theme */
$mainColor      : #444 !default;
/* Light        : #573454 Dark: #3b2639 -moz-linear-gradient(top, #fca99b 0%, #6e2842 100%) */
$fontColor      : #ddd !default;
/* l            : #d8d7db */
$fontColorActive: #f8f8f8 !default;

$mainDkColor : rgba(0, 0, 0, 0.2) !default;
/* darken($mainColor, 4%) - #383838 */
$mainDklColor: rgba(0, 0, 0, 0.1) !default;
$mainLhColor : rgba(255, 255, 255, 0.1) !default;
/* #515151 */
$mainLhlColor: rgba(255, 255, 255, 0.7) !default;
$fontColorDk : #777 !default;
$colorBlue   : #3b97e3 !default;
$colorRed    : #dd3636 !default;
$colorYell   : #ffca6f !default;
$colorGreen  : #62c462 !default;
$tagBg       : #804f7b !default;
$secColor    : $tagBg !default;
$imageCompDim: 50px !default;
$leftWidth   : 15% !default;

/* Color Helpers */
$colorHighlight: #71b7f1 !default;
$colorWarn     : #ffca6f !default;

/* Canvas */
$hndlMargin: -5px !default;

/* Components / Inputs */
$lightBorder   : rgba(255, 255, 255, 0.05) !default;
$inputFontColor: $mainLhlColor !default;
/* #d5d5d5 */
$arrowColor    : $mainLhlColor !default;
/* b1b1b1 */
$darkTextShadow: $mainDkColor !default;
/* #252525 */
$darkBorder    : rgba(0, 0, 0, 0.15) !default;
/* 303030 */
$colorpSize    : 22px !default;
$inputPadding  : 5px !default; // Has to be a single value

/* Class manager */
$addBtnBg : lighten($mainDkColor, 10%) !default;
$paddElClm: 5px 6px !default;

/* File uploader */
$uploadPadding: 150px 10px !default;

/* Commands */
$animSpeed: 0.2s !default;

/* Fonts */
$mainFont: "Poppins",
sans-serif !default;
// $mainFont: Helvetica,
// sans-serif !default;
$fontPath : './fonts' !default;
$fontName : 'main-fonts' !default;
$fontSize : 0.7rem !default;
$fontSizeS: 0.75rem !default;
$fontV    : 20 !default; //random(1000)

/* Tools */
$placeholderColor: $colorBlue !default;

[artf]

Ok, so you're basically just changing the color palette, which can be easily achieved with simple CSS rules and it's already shown in the theming section here

[joukhar]

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

[dauvray]

Hello,
thank you for your wonderful work.
It would therefore be necessary to modify the documentation if sass is no longer available.

// Put your variables before the GrapesJS style import

// Palette variables
$primaryColor: #444;
$secondaryColor: #ddd;
$tertiaryColor: #804f7b;
$quaternaryColor: #d278c9;

// ...

@import "grapesjs/src/styles/scss/main.scss";

cheers

[quentin-bettoum]

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.

[artf]

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.

[quentin-bettoum]

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.

[joukhar]

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.

[bgrand-ch]

Hello,

I think that removing the SASS files from the package is a mistake.

Let's take the example of the use of a bundler (80% of the cases):

If you import the CSS file and want to modify some styles, you end up with the entire imported CSS file + all the modified styles.

If you import the SASS file and want to modify some styles, you end up with a single CSS file that has been generated and optimised.

SASS is really dev-friendly.

Love SASS! Love GrapesJS! Please keep both!

Thanks.

[artf]

@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.

[artf]

Huge thanks to @quentin-bettoum for his PR #5437

[bgrand-ch]

@quentin-bettoum ❤️