DEV Community


Posted on

PR 1 for release 0.3

For our release 0.3 project we were to make a pull request for a external project outside of our class's repos and one pull request for an internal repo. For my external PR I worked and still am working on a library project that my professor maintains outside of Seneca called Filer. Filer is a drop-in library that works like node's fs module but for browsers. The issue I was working on was making a migration of parcel 1 to parcel 2.

I have never done a migration before so I figured it would be a good learning experience and also something not too complicated to do. Turns out despite it not require too many lines of code it can be more complicated than expected. I was able to follow along their migration instructions to update any lines of code that needed changing. Such as updating <script> to include a module type where needed.

<script type="module" src="../node_modules/chai/chai.js"></script>
Enter fullscreen mode Exit fullscreen mode

I also had to update the package.json with new arguments in scripts, and provide new properties to it such as target and paths to specific files.

The complicated part came in when I tried to test the program after the migration changes. For some reason parcel 2 was having trouble seeing built-in node_modules types such as buffer and path. It would give this error when tested:

$ npm test
× Build failed.

@parcel/core: Failed to resolve 'path' from './src/path.js'

    11 |  */
  > 12 | const nodePath = require('path');
  >    |                          ^^^^^^
    13 | const filerPath = Object.assign({}, nodePath);
    14 |

@parcel/resolver-default: External dependency "path" is not declared in package.json.

    48 |   },
  > 49 |   "dependencies": {
  >    |   ^^^^^^^^^^^^^^
    50 |     "buffer": "^6.0.3",
    51 |     "chai": "^4.3.4",

  ℹ Add "path" as a dependency.
Enter fullscreen mode Exit fullscreen mode

This would require adding the dependencies as external dependencies. But that wouldn't be what we wanted to do because of outdated versions. We wanted to use the versions that already existed inside of the node_modules folder. Thus, I spent hours trying to find the solution to our problem. Through this I learned that GitHub had built-in FAQ sections and that allowed me to easily browse through other people's questions and issues. I managed to find a similar issue where the person's node_modules were seen as external, but after trying their solution it would still give the same error. Thus, after searching issues and questions I made a new issue report to hopefully get the answer.

This PR is still a work in progress, but I learned a lot about migration and learned more about using GitHub as well in the process. Despite it seeming like a pretty simple issue on paper its cool to see that I was able to learn some stuff and gain experience with this type of task. If any of you reading want to take a look at the issue feel free to do so. Hopefully I will be able to make an update soon once I get a response for my issue, but until then take care!

Top comments (0)