Skip to content
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

Assert that sourcemaps are actually valid + empty map issue #51

Closed

Conversation

johnnyshields
Copy link
Contributor

One of the tests (below) is failing as it is not valid to have an empty sourcemap:

  it('can ignore empty content', function() {
    var node = concat(firstFixture, {
      outputFile: '/nothing.js',
      inputFiles: ['nothing/*.js'],
      allowNone: true
    });
    builder = new broccoli.Builder(node);
    return builder.build().then(function(result) {
      expectValidSourcemap('nothing.js').in(result);
    });
  });
{"version":3,"sources":[],"sourcesContent":[],"names":[],"mappings":"","file":"nothing.js"}
  1) sourcemap-concat can ignore empty content:
     AssertionError: There were no sources in the file

@johnnyshields johnnyshields changed the title Assert that sourcemaps are actually valid Assert that sourcemaps are actually valid + empty map issue Feb 7, 2016
@johnnyshields
Copy link
Contributor Author

@ef4 you might want to take a look at this. There is one existing test case which is not generating a valid sourcemap (i.e. fails validation using a the sourcemap-validator lib on NPM)

@Turbo87
Copy link
Contributor

Turbo87 commented Jun 1, 2016

@johnnyshields sorry for causing the conflicts on your branch, can you rebase on master?

@@ -294,8 +285,7 @@ describe('sourcemap-concat', function() {
});
builder = new broccoli.Builder(node);
return builder.build().then(function(result) {
expectFile('nothing.js').in(result);
expectFile('nothing.map').in(result);
expectValidSourcemap('nothing.js').in(result);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe we should keep using expectFile() here and add a code comment about why expectValidSourcemap() is not used

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we are generating a .map file, it should always pass validation. Otherwise, downstream parsers may choke on the map--many of them are quite brittle.

An alternative would be to not generate a .map file.

The current behavior--generating an invalid .map--is not acceptable IMHO.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stefanpenner any opinions on this?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that we should not generate an invalid map file. We could generate a valid one that has nothing in it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could generate a valid one that has nothing in it.

if I understand the situation correctly that is what we are currently doing. we are generating a map for nothing/*.js but the whole nothing folder doesn't exist, which results in sources of the map being empty, which according to the validator is invalid.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although not perfect, it would seem that:

  1. an empty map file is valid, if someone asks for a map they get a map even if it is empty, as long as it is well formed.
  2. the validate tool seems to not handle this case correctly.
  3. unless new information surfaces, we should: skip the validator for this one scenario, and continue the existing behavior

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@johnnyshields
Copy link
Contributor Author

@Turbo87 I've done the rebase. Please take over this PR and fix as necessary.

@Turbo87
Copy link
Contributor

Turbo87 commented Jun 1, 2016

awesome, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants