-
Notifications
You must be signed in to change notification settings - Fork 18
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
Missing --load-path option #67
Comments
Hey @justin-oh , I suppose some IDEs like PhpStorm may refactor those import paths for you when you move files in a different dir. Kinda of an edge case, I also don't think we strongly need this because mostly you don't move files around so that long/ugly path is written only once. I wonder if someone else is experiencing similar problems in their project. But I'm not against this |
I'm unsure what the accepted approach would be. Simple ApproachIf we assume Sass files would only be loaded from the $buildOptions[] = '--load-path='.escapeshellarg($this->projectRootDir.'/node_modules');
$buildOptions[] = '--load-path='.escapeshellarg($this->projectRootDir.'/vendor'); It Gets ComplicatedIf the need is to actually support a configurable However, the SassBuilder's current options are all assumed to be simple values like strings and booleans. Array consideration would need to be added. Further, the config keys are expected to essentially match what is offered by Sass. It would be preferable to name the new config value Overhaul Needed?Upon reviewing the way those options are handled, I think they should be overhauled so they aren't passed into the SassBuilder as an array parameter with a corresponding map, but handled through various helper functions specific to certain options. Currently, everything is being handled in a loop which starts to get out of hand quite easily. There are Here is my proposed approach where the SassBuilder class has several properties that are specific to certain arguments. There is no loop. There is just a series of checks to determine if an option/argument needs to be added as the command is being built: class SassBuilder
{
// these are the only values Sass allows for --style
const STYLE_COMPRESSED = 'compressed';
const STYLE_EXPANDED = 'expanded';
// this is the default as defined by Sass
private string $style = self::STYLE_EXPANDED;
// this covers the --charset and --no-charset arguments
// which should never exist together, so it makes sense to control them with a boolean variable
private boolean $charset = false;
// etc.
public function __construct(
private readonly array $sassPaths,
private readonly string $cssPath,
private readonly string $projectRootDir,
private readonly ?string $binaryPath,
) {
}
// with these 2 functions, there is no way to set a value that Sass will be angry about
public function setStyleCompressed(): self
{
$this->style = self::STYLE_COMPRESSED;
return $this;
}
public function setStyleExpanded(): self
{
$this->style = self::STYLE_EXPANDED;
return $this;
}
// however, if the above 2 functions makes implementation difficult
// then it is easy enough to have the following and rely on proper usage
public function setStyle(string $style): self
{
$this->style = $style;
return $this;
}
public function setCharset(bool $charset): self
{
$this->charset = $charset;
return $this;
}
// etc.
// building out the command based on the helper properties
// such that there is no way to have arguments that contradict each other
public function buildCommand()
{
$options = [];
$options[] = '--style='.$this->style;
if ($this->charset) {
$options[] = '--charset';
} else {
// this is redundant by Sass documentation as it is the default behaviour
$options[] = '--no-charset';
}
// etc.
}
} To complete what is currently implemented means adding a bunch of boolean properties like charset to correspond with the remaining options (ie. To integrate private array $loadPaths = [];
public function __construct(
private readonly array $sassPaths,
private readonly string $cssPath,
private readonly string $projectRootDir,
private readonly ?string $binaryPath,
) {
// possibly add node_modules and vendor here as convenient defaults
$this->loadPaths[] = $projectRootDir.'/node_modules';
$this->loadPaths[] = $projectRootDir.'/vendor';
}
public function addLoadPath(string $loadPath): self
{
$this->loadPaths[] = $loadPath;
}
public function buildCommand()
{
// ...
// possibly apply array_unique to $this->loadPaths
foreach ($this->loadPaths as $loadPath) {
$options[] = '--load-path='.escapeshellarg($loadPath);
}
} |
In the documentation for integrating Bootstrap, it is recommended to
composer require twbs/bootstrap
then@import '../../vendor/twbs/bootstrap/scss/bootstrap'
. It becomes cumbersome, tedious, ugly, etc. to maintain relative pathing like that. If you have to move a file, you must update these paths.To make matters worse, I have my own bundle with a
Resources/public
directory that copies some Sass into thepublic
directory of the Symfony project. So now I have to think like this:I could of course not put the Sass file in the public directory, but my import would still look ugly:
I don't think the
--load-path
option would necessarily need to be exposed to the developer, but it would be nice if the bundle provided some basic/common load paths like this:Then we can at least have more readable/maintainable Sass imports for 3rd party code:
The text was updated successfully, but these errors were encountered: