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

README update about gulp4 #365

Open
nmccready opened this issue Feb 1, 2019 · 8 comments
Open

README update about gulp4 #365

nmccready opened this issue Feb 1, 2019 · 8 comments

Comments

@nmccready
Copy link
Collaborator

@phated can you modify the main README.md with information about sourcemaps being rolled into the core of gulp4. I feel you fill out this info the best.

This is one the main reasons this library has stopped being updated. This is the main reason why css updates have not been done yet.

But I guess this could help those that are stuck on gulp3. Then again my time is limited.

@benjclark
Copy link

@nmccready
I have discovered that there is still value in maintaining aspects of gulp-sourcemaps even though Gulp 4 now provides sourcemaps functionality.

Specifically it's the option loadmaps: true. That is not present in Gulp 4, therefore we still need to use a package like this to leverage existing sourcemaps in build steps. An example of this is in a build step that revisions files in production. That build step needs to leverage the sourcemaps created in a previous js (or scss) compilation build step. From what I can tell this cannot be done in Gulp 4 but can be done using this package.

@nmccready
Copy link
Collaborator Author

10-4, well maybe I will dig in an finish my PR for switching css processing to postcss.

@phated
Copy link
Contributor

phated commented Feb 11, 2019

@nmccready the goal is to move any extra features out the namespaced @gulpsourcemaps modules like I had been doing. Once all those extra features are deferred, the main module will be a direct copy of what gulp uses and then it can be deprecated. I have literally zero time to keep moving on that but if you are making changes, they should happen in a namespaced module and pulled in like the other modules.

@benjclark
Copy link

benjclark commented Feb 12, 2019

Does this mean you guys have no intention to fix this issue with the loadmaps option (#363)? Please let me know as if so I'll move our organisation on to a different solution. Thanks.

@nmccready
Copy link
Collaborator Author

nmccready commented Feb 12, 2019

Does this mean you guys have no intention to fix this issue with the loadmaps option (#363)? Please let me know as if so I'll move our organisation on to a different solution. Thanks.

I am still working on that PR, I will be resuming it today.

If I wasn't the issue would be closed.

@benjclark
Copy link

@nmccready Ah ok, thank you. Wasn't sure but yes that makes sense. Thanks.

@nmccready
Copy link
Collaborator Author

nmccready commented Feb 12, 2019

I am going to close this issue as I don't see sourcemaps fully evolving unless someone spear heads the source mapping at gulp. @phated is there a new figure head which is rolling in to take the burden off your shoulders since you're more of a Reason man now?

@phated
Copy link
Contributor

phated commented Feb 24, 2019

I think this is worthy to keep open. We have an issue at #285 that gathers the requirements needed for deprecating. I'll try to come up with a concise, yet detailed explanation for the README.

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

No branches or pull requests

3 participants