-
-
Notifications
You must be signed in to change notification settings - Fork 242
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
Allow Sass to import files even if they don’t have an item #1379
Conversation
459d701
to
683b306
Compare
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.