Support for scss files in bower packages

[dkebler]

For vendor (bower) packages the @import is not necessarily full path to the scss partial as the remaining portion is accessed via code like compass. So dependents won't find it because it's not within the "styles_root".

So I think like I am doing with gulp this node package https://github.com/ck86/main-bower-files
can be used to build an array of paths which Dependents can use to find and open and @import with nothing but the filename, just need to walk through this generated array.

kinda like this maybe

// https://github.com/ck86/main-bower-files
var sassBower    = require('main-bower-files');

// main-bower-files will then grab the full paths for all scss files only from "main" entry in each package's bower.json - 
// Unlike the hardcode in the call below will have to read .bowerrc file instead for actual bower components directory but main-bower-files option can do that I think
var scss_paths = sassBower({
  base: path.join(__dirname, "bower_components"),
  filter: '**/_*.scss'
});

for (var i=0; i<scss_paths.length; i++){
  // we need to use the parent directories of the main files, not the files themselves
  scss_paths[i] = path.dirname(scss_paths[i]);
}

so now check against scss_paths whenever Dependents fails after looking in/below "styles_root"

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[dkebler]

ok far below code works for case where locations of bower stuff are default. .bowerrc and bower.json in root of project. One would have to parse .bowerrc to discover "bower-components" directory if other than the default ./bower_components.

We could allow custom bower settings in .deprc for those with alternate bower.json and .bowerrc locations. Maybe a bower_root in .deprc which points to the directory where one finds .bowerrc and bower.json would be enough assuming they are always in the same path (extremely likely). Otherwise just need to look for .bowerrc in root and find the bower_components path there. If it doesn't exist we use default location "bower_components". Anything not default must be passed to main-bower-files. Could even just look for bower.json/.bowerrc as a matter of course without even a bower_root set.

A little help Joel outlining how you would attack incorporating this and I will try to do it. I've spent a little time looking at the repo and have some idea how all the pieces work for a sass jump to dependency. Focusing on jumptodependency.py, 'directory' could be one from the array of main-bower-files directories when the initial call with styles_root fails??? How about just modifying sass_lookup to handle an array of directories where when one fails it moves on to the next in the array until all are exhausted. We could prepend the directory from styles_root to this array before passing it???? If there is no bower_root in .deprc then the array can just be empty.

BTW I see you have a todo to change this python code into a node module, maybe that should been done as part of this change.

       if is_sass_file(module_with_extension):
            p('Sass lookup for:', module_with_extension)

            file_to_open = sass_lookup({
                'filename': self.view.filename,
                'directory': self.window.styles_root,
                'path': module_with_extension
            })

Does this only affect jump to dependecy? or get_dependents as well?

FYI whatever we do here could be used repeated for any language (mostly js) as bower has many js packages.

//////////////////////////////////////////////////////////

var path  = require('path');
var sassBower    = require('main-bower-files');
// this needs to be improved to get path to resolve from .bowerrc
var base_path = path.resolve('bower_components');

  // grab all the full paths
var scss_paths = sassBower({
  base: base_path,
  filter: '**/_*.scss',
  debugging: true,
  includeDev: true

});
  // strips out the filename from the path assuming this is wanted to pass to sass_lookup's directory parameter.
for (var i=0; i<scss_paths.length; i++){
  scss_paths[i] = path.dirname(scss_paths[i]);
} 

[mrjoelkemp]

Haven't forgotten about this and your other issues. Will try to provide
answers tonight.

On Wed, Jul 8, 2015 at 1:07 PM, dkebler [email protected] wrote:

ok far below code works for case where locations of bower stuff are
default. .bowerrc and bower.json in root of project. One would have to
parse .bowerrc to discover "bower-components" directory if other than the
default ./bower_components.

We could allow custom bower settings in .deprc for those with alternate
bower.json and .bowerrc locations. Otherwise just need to look for .bowerrc
in root and find the bower_components path there. If it doesn't exist we
use default location "bower_components". Anything not default must be
passed to main-bower-files.

A little help Joel outlining how you would attack incorporating this and I
will try to do it. I've spent a little time looking at the repo and have
some idea how all the pieces work for a sass jump to dependency. Seems
changes or additions to this code in jumptodependency.py. 'directory' could
be one from the array of main-bower-files directories when the initial call
with styles_root fails??? How about just modifying sass_lookup to handle an
array of directories where when when one fails it moves on to the next in
the array until all are exhausted. We could prepend the directory from
styles_root to this array before passing it????

   if is_sass_file(module_with_extension):
        p('Sass lookup for:', module_with_extension)

        file_to_open = sass_lookup({
            'filename': self.view.filename,
            'directory': self.window.styles_root,
            'path': module_with_extension
        })

Does this only affect jump to dependecy? or get_dependents as well?

//////////////////////////////////////////////////////////

var path = require('path');
var sassBower = require('main-bower-files');
// this needs to be improved to get path to resolve from .bowerrc
var base_path = path.resolve('bower_components');

// grab all the full paths
var scss_paths = sassBower({
base: base_path,
filter: '*_/__.scss',
debugging: true,
includeDev: true

});
// strips out the filename from the path assuming this is wanted to pass to sass_lookup's directory parameter.
for (var i=0; i<scss_paths.length; i++){
scss_paths[i] = path.dirname(scss_paths[i]);
}

—
Reply to this email directly or view it on GitHub
#155 (comment)
.

[mrjoelkemp]

Thanks for all of the detail here. Outside of the implementation, I'm not sure what this features gives us. Can you provide a sample link to a project where this feature would be useful? Is there a bowered module that is solely a scss file?

A little help Joel outlining how you would attack incorporating this and I will try to do it.

Though I'm not understanding the need for this feature, I'd focus on sass first by putting this lookup logic right into https://github.com/mrjoelkemp/node-sass-lookup. The goal with all of these features and my TODO is to move more and more logic out of the python code and into node modules. This allows us to reuse logic across multiple editors.

Eventually, there might be a single sublime-dependents-backend repo that has all of the shell scripts that the Sublime plugin executes all under one roof.

If the feature proves useful, then it would either get integrated into other lookup modules like https://github.com/mrjoelkemp/node-stylus-lookup or a new abstraction could be used.

[dkebler]

So I am assuming you have never used Bower for 3rd party code managment?

In the case of styling and now using Gulp code I put together (Compass did
this prior) I have a _vendor.scss file that contain various @imports to
bower scss packages but with just the filename (will automate this too).
Gulp now includes these while pre-processings my scss to css with no more
than the filename by using main-bower-files. But if I want to look at that
code in sublime well then I have to know where that file is located and dig
around to open it because Dependents as is will look for this under
styles_root where these files are not located.

So in general allowing Dependents to accept an array of possible "root"
locations would be more flexible and not just for my case.

How about if Dependents supported accepting a user defined function that
returns an array of paths and uses them in order for searching. Then
Dependents wouldn't need concern itself with users reasons or specifics
like they are using Bower.

SO ------------------

To your end of moving this logic out of python to js maybe some thought on
the whole process of accepting user dependents/dependency requests.

I see two user supplied pieces.

1. The filename(s) to look for from the parsed inclusion line in their
   code including for example what extension(s), prepends...etc.
2. Where to look for this file

How about two user defined functions for these.

1. Accpets a filename parsed out of the code by Dependents (without
   extension or prepends) and returns an array of filename variants to look
   for (e.g. test.scss, _test.scss, test.sass),
2. Returns an array of paths within which to search (like I suggest
   above). This could (should?) include the path we are calling the ???_root
   in .deprc now.

So for any supported language user would need to register with Dependents

1. their extension=>inclusion word pairs. For example .scss =>
   @import. (I assume this is how it works now.... if the open file
   extension is .scss then Dependents accepts a cursor on a line if it
   contains @import ???).
2. Their two user coded functions described above.

---

I would like to make Dependents work with my Hugo html
http://gohugo.io/templates/partials/ templating code . In fact there are
many html templating languages out there now each with a bit different
syntax like nunjucks
http://mozilla.github.io/nunjucks/templating.html#include. Thus I don't
see you personally writing specific code for each language. Clearly you
need a way of getting yourself out the specific language support. In fact
if someone wanted support for their language and could not write their own
js Dependent "plugin" functions with the documentation provided (as I
propose) then you could offer to write them for a fee.

So how does this approach sound implementation wise? Maybe you should
close this particular issue (bower support) and we open up one more general
about "plugin" language support.

On Thu, Jul 9, 2015 at 6:20 PM, Joel Kemp [email protected] wrote:

Thanks for all of the detail here. Outside of the implementation, I'm not
sure what this features gives us. Can you provide a sample link to a
project where this feature would be useful? Is there a bowered module that
is solely a scss file?

A little help Joel outlining how you would attack incorporating this and I
will try to do it.

Though I'm not understanding the need for this feature, I'd focus on sass
first by putting this lookup logic right into
https://github.com/mrjoelkemp/node-sass-lookup. The goal with all of
these features and my TODO is to move more and more logic out of the
python code and into node modules. This allows us to reuse logic across
multiple editors.

Eventually, there might be a single sublime-dependents-backend repo that
has all of the shell scripts that the Sublime plugin executes all under one
roof.

If the feature proves useful, then it would either get integrated into
other lookup modules like https://github.com/mrjoelkemp/node-stylus-lookup
or a new abstraction could be used.

—
Reply to this email directly or view it on GitHub
#155 (comment)
.

Cheers, Cuidate, TTFN http://www.youtube.com/watch?v=5Gu50vq5ux4
David

[dkebler]

FYI node-sasshttps://github.com/sass/node-sass supports an array of path
locations like I suggest for Dependents which is why the Gulp code with
main-bower-files works. So Dependents could operate like this.
includePaths

Type: Array Default: []

An array of paths that libsass https://github.com/hcatlin/libsass can
look in to attempt to resolve your @import declarations. When using data,
it is recommended that you use this.

On Fri, Jul 10, 2015 at 9:45 AM, David Kebler [email protected] wrote:

So I am assuming you have never used Bower for 3rd party code managment?

In the case of styling and now using Gulp code I put together (Compass did
this prior) I have a _vendor.scss file that contain various @imports to
bower scss packages but with just the filename (will automate this too).
Gulp now includes these while pre-processings my scss to css with no more
than the filename by using main-bower-files. But if I want to look at that
code in sublime well then I have to know where that file is located and dig
around to open it because Dependents as is will look for this under
styles_root where these files are not located.

So in general allowing Dependents to accept an array of possible "root"
locations would be more flexible and not just for my case.

How about if Dependents supported accepting a user defined function that
returns an array of paths and uses them in order for searching. Then
Dependents wouldn't need concern itself with users reasons or specifics
like they are using Bower.

SO ------------------

To your end of moving this logic out of python to js maybe some thought on
the whole process of accepting user dependents/dependency requests.

I see two user supplied pieces.

1. The filename(s) to look for from the parsed inclusion line in their
   code including for example what extension(s), prepends...etc.
2. Where to look for this file

How about two user defined functions for these.

1. Accpets a filename parsed out of the code by Dependents (without
   extension or prepends) and returns an array of filename variants to look
   for (e.g. test.scss, _test.scss, test.sass),
2. Returns an array of paths within which to search (like I suggest
   above). This could (should?) include the path we are calling the ???_root
   in .deprc now.

So for any supported language user would need to register with Dependents

1. their extension=>inclusion word pairs. For example .scss =>
   @import. (I assume this is how it works now.... if the open file
   extension is .scss then Dependents accepts a cursor on a line if it
   contains @import ???).
2. Their two user coded functions described above.

---

I would like to make Dependents work with my Hugo html
http://gohugo.io/templates/partials/ templating code . In fact there are
many html templating languages out there now each with a bit different
syntax like nunjucks
http://mozilla.github.io/nunjucks/templating.html#include. Thus I
don't see you personally writing specific code for each language. Clearly
you need a way of getting yourself out the specific language support. In
fact if someone wanted support for their language and could not write their
own js Dependent "plugin" functions with the documentation provided (as I
propose) then you could offer to write them for a fee.

So how does this approach sound implementation wise? Maybe you should
close this particular issue (bower support) and we open up one more general
about "plugin" language support.

On Thu, Jul 9, 2015 at 6:20 PM, Joel Kemp [email protected]
wrote:

Thanks for all of the detail here. Outside of the implementation, I'm not
sure what this features gives us. Can you provide a sample link to a
project where this feature would be useful? Is there a bowered module that
is solely a scss file?

A little help Joel outlining how you would attack incorporating this and
I will try to do it.

Though I'm not understanding the need for this feature, I'd focus on sass
first by putting this lookup logic right into
https://github.com/mrjoelkemp/node-sass-lookup. The goal with all of
these features and my TODO is to move more and more logic out of the
python code and into node modules. This allows us to reuse logic across
multiple editors.

Eventually, there might be a single sublime-dependents-backend repo that
has all of the shell scripts that the Sublime plugin executes all under one
roof.

If the feature proves useful, then it would either get integrated into
other lookup modules like
https://github.com/mrjoelkemp/node-stylus-lookup or a new abstraction
could be used.

—
Reply to this email directly or view it on GitHub
#155 (comment)
.

Cheers, Cuidate, TTFN http://www.youtube.com/watch?v=5Gu50vq5ux4
David

Cheers, Cuidate, TTFN http://www.youtube.com/watch?v=5Gu50vq5ux4
David

[mrjoelkemp]

Supporting multiple roots is high on my list of features to implement. We get frustrated at work when we can't use JumpToDependency for every and any dependency path.

I think the key to make this work involves:

1. Modify Dependents to support the paths setting and the single path setting for back compat.
2. Update sass_lookup to check the additional paths for the file if normal resolution fails.
3. Update dependents to accept a list of files and incorporate it into the glob that grabs all files to process: https://github.com/mrjoelkemp/node-dependents/blob/947b38fbc55599154680e2340a1849317d21cdc1/index.js#L156.
4. There are likely other node libs powering Dependents that would need to be adjusted.