Nixinova / LinguistJS

Analyse and list all languages used in a folder. Implementation of and powered by GitHub's Linguist.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

`offline` not working when using linguist-js as library

hstaudacher opened this issue · comments

I just started linguist-js as library and it's pretty nice :). I have discovered that using it out of a unit test e.g. mocha with the offline option set to true will lead to an error. For me the message is:

Error: ENOENT: no such file or directory, open '{MY_PATH}/ext/languages.yml'

where {MY_PATH} is the path to my ../project. It seems the loading via ../../ in loadData is not made for this kind of use. It would be very cool if this could be stabilized.

Thinking about this more I think a valid enhancement could be to allow passing an own set of linguist yml files. Raw or already parsed would be another option.

With this the library would be decoupled from the actual yml files which means a consumer could update the yml files without the need for this library to create a new release.

What do you think?

Hi, thanks for the report.

I have discovered that using it out of a unit test e.g. mocha with the offline option set to true will lead to an error.

Do you have a reproduction for this issue? Because the offline option works fine when I make a repo with this as index:

import linguist from 'linguist-js';

const data = await linguist('.', { offline: true });

console.debug(data);
//C:\Users\user\AppData\Local\Temp\20230117>node index.mjs
{
  files: {
    count: 2,
    bytes: 367,
    results: {
      'C:/Users/user/AppData/Local/Temp/20230117/index.mjs': 'JavaScript',
      'C:/Users/user/AppData/Local/Temp/20230117/package.json': 'JSON'
    }
  },
  languages: {
    count: 2,
    bytes: 367,
    results: { JavaScript: [Object], JSON: [Object] }
  },
  unknown: { count: 0, bytes: 0, extensions: {}, filenames: {} }
}

And I did confirm the offline option was working properly by going on airplane mode, heh.

Thinking about this more I think a valid enhancement could be to allow passing an own set of linguist yml files. Raw or already parsed would be another option.
With this the library would be decoupled from the actual yml files which means a consumer could update the yml files without the need for this library to create a new release.

Hm, this seems like it would have a lot of overhead for not a lot of benefit. Having lag from the upstream yml files doesn't seem like a big deal - if you want the very latest you can use online mode, if you want stability and insurance that it will work correctly you can use offline mode. I don't feel like allowing custom yaml files would be too useful a feature. Do you have a use case where custom yml files would be a useful feature to have?

@hstaudacher can you provide more information about how to reproduce this issue?

Using Linguist in a Mocha test seems to work just fine:

const assert = require('assert');
const linguist = require('linguist-js');
describe('Linguist', function () {
    describe('issue#18', function () {
        it('should linguist()', async function () {
            const data = await linguist('.', { offline: true });
            assert.equal(data.languages.count, 2);
        })
    });
});
>npx mocha


  Linguist
    issue#18
      √ should linguist() (134ms)


  1 passing (142ms)

Closing as not repoducable.