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

yarn-support #488

Merged
merged 7 commits into from
Jun 17, 2017
Merged

yarn-support #488

merged 7 commits into from
Jun 17, 2017

Conversation

mattiaerre
Copy link
Member

Description

see #487

  • get template by name

  • fix test

I've added a require by name step before the existing require by path ones; I've also added some small refactoring. I've tested this fix locally and it looks like it works w/ both npm and yarn.

Coverage report

 PASS  __tests__/src/utils/require-template.test.js
  requireTemplate
    ✓ expect type of `requireTemplate` to be function (3ms)
    valid
      ✓ oc-template-handlebars (68ms)
      ✓ oc-template-jade (267ms)
    not valid
      ✓ lodash (35ms)
      ✓ oc-invalid-template (3ms)

Test Suites: 1 passed, 1 total
Tests:       5 passed, 5 total
Snapshots:   4 passed, 4 total
Time:        1.432s
Ran all test suites.
---------------------|----------|----------|----------|----------|----------------|
File                 |  % Stmts | % Branch |  % Funcs |  % Lines |Uncovered Lines |
---------------------|----------|----------|----------|----------|----------------|
All files            |       96 |     87.5 |      100 |       96 |                |
 require-template.js |       96 |     87.5 |      100 |       96 |             24 |
---------------------|----------|----------|----------|----------|----------------|

}
ocTemplate = require(localTemplate);
} catch(err) {
ocTemplate = getOcTemplate(template);
Copy link
Member Author

Choose a reason for hiding this comment

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

this is the only "new" code I've added that tries to fix the yarn issue.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Sorry about my ignorance, but how can that change affect over the yarn installation behavior? I only see you moved the logic to a function 😕

Copy link
Member Author

Choose a reason for hiding this comment

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

Hi,
Yes I moved the logic into a function but I've also added an additional check of getting the template by name (line 35).
Try to do this: install OC globally w/ yarn and make sure your publish doesn't work. Then replace require-template.js in the yarn OC global folder w/ the file I've changed and see if that fixes. Thanks!

Copy link
Collaborator

Choose a reason for hiding this comment

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

I've just tried it, and I can't publish due to this: npm/npmlog#48

imatge

😕

Copy link
Member Author

Choose a reason for hiding this comment

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

this is another problem; you need to rm -rf node_modules first, it is a known issue w/ npmlog when switching between npm and yarn 😢

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yeah, I was doing it now... and then I face with this...

imatge

After seeing the error... I thought that maybe your changes now could allow me to publish from the widget folder itself, so I tried:

imatge

the neverending story... 😅

Copy link
Member Author

Choose a reason for hiding this comment

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

infinite-loop-loader tells us everything hehehe 😊 feel free to collaborate on this branch; I will not be able to follow this issue as I'll be offline for a couple of days but either @matteofigus or @nickbalestra should be able to have a look at this.

Copy link
Collaborator

Choose a reason for hiding this comment

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

After manually installing infinite-loop-loader (ofc only for this test) everything works as expected! 😃

Copy link
Member Author

Choose a reason for hiding this comment

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

very good; we are getting there 😉 thanks for your help!

// cc @matteofigus @nickbalestra

@mattiaerre
Copy link
Member Author

@matteofigus @nickbalestra @elboletaire not sure if we decided how to proceed w/ this issue; infinite-loop-loader was the last blocker we had.

@matteofigus matteofigus added the wip label Jun 7, 2017
@mattiaerre
Copy link
Member Author

@matteofigus shall we have a conversation and decide how to proceed w/ this?

// cc @nickbalestra @elboletaire

@matteofigus
Copy link
Member

@mattiaerre sorry for taking long to reply to this.

Unfortunately requiring by name doesn't work. You want to require the template from the CLI local to the component. Requiring by name requires it local to the CLI, which happens to work currently for the jade/handlebars ones, but that will change soon in favour of taking those two off from the CLI (making the require by name attempt basically not useful).

Now, getting back to the issue. I am not very expert about yarn, but this seems to be a yarn problem to me. There is a package.json, yarn is not installing all the deps during the install, so I would open a issue in their repo rather than here.

@matteofigus
Copy link
Member

@nickbalestra please can you review what I just said makes sense? lol

return require(path);
};

module.exports = function (template) {
let ocTemplate;
const localTemplate = path.join(
Copy link
Member

Choose a reason for hiding this comment

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

I think we need to understand, in case of yarn install, why this doesn't work. The oc-template-jade module must be there if yarn installed everything correctly, if it is not we need to find out where it is

Copy link
Member

Choose a reason for hiding this comment

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

Same for the infinite-loop-loader. It should be in the node_modules.

@matteofigus matteofigus mentioned this pull request Jun 13, 2017
@matteofigus
Copy link
Member

Ok...I apology for previous comments.
I finally managed to reproduce.
Summarising:
yarn global add oc installs oc into => /Users/mfigus/.nvm/versions/node/v6.10.2/bin/oc
That thing is a symlink to => /Users/mfigus/.config/yarn/global/node_modules/oc/

Now...If I go in that node_modules folder, it's pretty empty. The main reason, is that if I go 1 level down (/Users/mfigus/.config/yarn/global/node_modules/) the dependencies (including infinite-loop-loader and oc-template-handlebars) are there already. So, I believe yarn tries to be smart and doesn't install them, but in the module we actually require it from the oc's node_modules.

So, in conclusion, I believe @mattiaerre's approach in this PR is correct and will fix.
So, I am approving this PR.

Copy link
Member

@matteofigus matteofigus left a comment

Choose a reason for hiding this comment

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

@mattiaerre I am ok with the approach.
Before merging:

  1. I prefer not including the yarn lock file. I am ok supporting yarn, but I would remove the lock file
  2. I am not sure about the jest tests here. We have another PR to discuss and I am personally happy about it, but for limiting this PR's scope my preference would be not to use jest. Feel free to disagree...as said, I have mixed feelings, we need to start with something at some point.

@elboletaire
Copy link
Collaborator

+1 to what @matteofigus said about the yarn.lock file. It's ok to include it in final projects, but not in libraries (exactly how composer.lock works for php projects). So it should not be included in oc.

And I also think that, if we don't currently have testing, we should not merge issues. Let's add a new issue for adding tests. Given the moment, @mattiaerre will be able to cherry-pick the changes from his branch to the new PR.

@mattiaerre
Copy link
Member Author

thank you for your feedback @elboletaire I adapted my tests to use mocha and it looks like I've been able to achieve the same result w/o Jest (although no snapshots, unfortunately); apart from that I think that this is a decent refactoring so as long as we are good w/ infinite-loop-loader this PR is over to you for a review and no longer WIP

a quote from @ericelliott

Open source etiquette requires a "when in Rome" attitude. Don't make major changes to tech or style without discussing it first.

source: twitter

// cc @matteofigus @nickbalestra

@mattiaerre mattiaerre changed the title [DO NOT MERGE] yarn-support yarn-support Jun 16, 2017
@mattiaerre mattiaerre removed the wip label Jun 16, 2017
@matteofigus
Copy link
Member

Nice quote 👍 It now LGTM. If it's good for you too, @elboletaire, can you merge?

Thanks

@elboletaire elboletaire merged commit 3ca8ffd into master Jun 17, 2017
@elboletaire
Copy link
Collaborator

elboletaire commented Jun 17, 2017

Done @matteofigus. Thanks for the fix @mattiaerre !!

@matteofigus matteofigus deleted the yarn-support branch June 17, 2017 12:14
@mattiaerre
Copy link
Member Author

@elboletaire thank you!

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

Successfully merging this pull request may close these issues.

3 participants