Allow Sass to import files even if they don’t have an item #1379
Conversation
denisdefreyne
force-pushed
the
sass-load-even-if-file-does-not-exist
branch
from
459d701
to
683b306
Compare
denisdefreyne
force-pushed
the
sass-load-even-if-file-does-not-exist
branch
from
683b306
to
3f3c76d
Compare
| @@ -20,15 +20,16 @@ def find_relative(name, base_identifier, options) | |||
| return unless raw_filename | |||
|
|
|||
| item = raw_filename_to_item(raw_filename) | |||
| # it doesn't make sense to import a file, from Nanoc's content if the corresponding item has been deleted | |||
| raise "unable to map #{raw_filename} to any item" if item.nil? | |||
There was a problem hiding this comment.
Alright, this line indeed makes the compilation stop.
I think you should replace
# it doesn't make sense to import a file, from Nanoc's content if the corresponding item has been deleted
raise "unable to map #{raw_filename} to any item" if item.nil?
by
# the imported file doesn't correspond to a Nanoc item, let next importer in Sass' :load_paths handle it
return if item.nil?
And keep the rest of importer.rb as it is.
This suggestion alone fixes #1378.
There was a problem hiding this comment.
As discussed on Gitter, this won’t work with paths that are relative to the item itself and live outside of the Nanoc content directory.
e.g. current item = content/style/foo.sass, path to import = `../../external.sass'
| options[:importer] = self | ||
| ::Sass::Engine.new(item.raw_content, options) | ||
| ::Sass::Engine.new(content, options) |
There was a problem hiding this comment.
I understand why you're doing it. Indeed it may be desirable to keep backward compatibility and let people @import with relative paths where imported files live outside of Nanoc's content/ directory instead of importing relatively from a configured entry in load_paths
| @@ -0,0 +1,25 @@ | |||
| # frozen_string_literal: true | |||
|
|
|||
| describe 'GH-1378', site: true, stdio: true do | |||
There was a problem hiding this comment.
Totally cool to learn how to assemble a "real site" instead of having to mock all Nanoc internals 👍
There was a problem hiding this comment.
This is in particular used for regression tests, although I have also started writing integration tests in spec/nanoc/integration.
It’s not a substitute for unit tests, though, because the integration/regression tests tend to run slowly and so it’s not great for testing all the different cases.
|
As suggested by @gpakosz: a useful refactoring later on might be to have two importer classes — one that deals with Nanoc items exclusively, and one that deals with importing relative files not belonging to a Nanoc item. That’d break up the responsibilities of the two importers a bit more nicely; currently, the single importer does a bit too much. |
Fix backwards-incompatible change in 4.10’s Sass filter.
Detailed description
When no load paths are given to the Sass filter, it should still be able to resolve relative paths (e.g.
../external) and successfully import. This isn’t currently possible, because the Sass filter assumes that the files have a corresponding Nanoc item.This change allows the Sass filter to (again) import such files.
To do
(Include the to-do list for this PR to be finished here.)
Related issues
Fixes #1378.