It'd be nice to have a tag to pull from instead of pulling and building from master on every build. On average my builds take 40-50 seconds to build the firebase action.

Is this possible? I know there are some other actions that I use that I don't have to build every time (actions/checkout, for example), but I've never published a GitHub Action myself so I'm not sure how to do it.

Thanks for the reply. Sounds like it'd require you to rewrite the action in JavaScript. I'll go ahead and close. Maybe I can just npm install firebase-tools and use that directly...

We could definitely provide an endpoint for versions, yes. In npm terms this data is typically provided in a "packument". I'll reopen for further discussion.

I've always thought of history.listen as more of an event emitter than a state machine. There are so many other tools for managing state (this.state/this.setState, useState, useReducer, etc).

I really don't want to throw another one on the pile 😅

Hey everyone, I just realized that I never commented on this issue when I closed it. Sorry about that!

For anyone who is wondering, I left an explanation in another issue about why I decided to leave this functionality out of the history library.

It basically boils down to this: history.push is just a substitute for window.history.pushState. It shouldn't try to be "smart" about doing e.g. a push vs. replace. If it did, we would lose something that the pushState API actually gives us, namely the ability to push the same URL onto the stack twice. There are valid use cases for doing so, and overloading the meaning of "push" in this library would just cause more issues and confusion.

However, the original concern is totally legit. This is why React Router's <Link> component is smart about this in v6 (currently in beta). If you take a look at the source, you'll notice that a <Link> uses a replace instead of a push when the URL is the same. I think this is the right place for this logic.

This way, history + React Router have parity with the DOM. Our history.push works exactly like window.history.pushState and React Router's <Link> works like a normal <a> element.

Again, my apologies for not following up here earlier! I definitely should have.

There has been a long-standing issue going on 4 years about how this library will repeat pushState when navigating to the page the user is currently on. This is a nuisance to the user experience. That said, what would it take to get that PR merged and get this issue to bed? Even @mjackson agreed that it has been a nuisance.

The behavior of browser history is as follows:

User navigates to /page-1
User navigates to /page-2
User navigates to /page-2
The back button returns the user to /page-1, not /page-2

Re: #570

history.push should not behave differently from window.history.pushState. If pushState adds a new location to the history stack (it does) then history.push should do the same thing. It's not this library's responsibility to make sure you aren't pushing duplicate URLs to the stack. That is the responsibility of code that uses this library.

For example, if you're using React Router v6 (currently in beta), the <Link> component automatically detects if you're pushing to the same location and uses a replace instead of a push action to mimic what standard <a> elements do.

Hope that helps!

It'd be nice to have a tag to pull from instead of pulling and building from master on every build. On average my builds take 40-50 seconds to build the firebase action.

Is this possible? I know there are some other actions that I use that I don't have to build every time (actions/checkout, for example), but I've never published a GitHub Action myself so I'm not sure how to do it.

What / Why

<!-- Describe the request in detail --> I'm unsure if this is the right place to ask something like this, but I was just wondering if y'all had any plans to continue sorting the entries in package.json's dependencies (and devDependencies) in v7 after an npm add or npm remove. It was a handy side effect that I used to quickly scan my dependencies in the past, and I'm kinda missing it in v7.

Thanks for all the great work you do!

Where

<!-- Examples

• npm enterprise
• npm public registry
• npm/<repository> -->
• npm cli v7

Who

<!-- Examples

• @npm/<team>
• @<username> -->
• n/a

References

<!-- Examples

• Related to #0
• Depends on #0
• Blocked by #0 -->
• n/a

I have a use case in a React application where I need to manipulate history stack by

• triggering history.goBack
• and then history.replace right after

However, I would like to bypass the listener for the first history.goBack call such that the route doesn't get rendered unnecessarily.

Public API doesn't seem to offer this kind of functionality. Would you be open to consider adding a capability to pause listeners?

It should be pretty easy to do this using the public API. history.listen returns a function you can use to stop listening for new locations, so just surround your call to goBack with an unlisten followed by a history.listen call.

Otherwise, keep a variable around and just ignore the change yourself, like:

let isPaused = false;
history.listen(location => {
  if (!isPaused) handleLocationChange(location);
});

function handleLocationChange(location) {
  // ...
}

// Somewhere in your app code
isPaused = true;
history.goBack();
isPaused = false;
history.replace();

I can't really understand why the previous location isn't exposed when using history.listen. This seems like critical information, especially given that route changes occur even on hash updates, which often need to be differentiated from actual route updates to determine whether or not to show a new screen.

let prevLocation = history.location;
history.listen(location => {
  // Do whatever you want with the previous location here.
  prevLocation = location;
});

Is there a particular reason you need this? This isn't a node library, per se.

We have iframe based micro-frontends. There is a need of changing the state of the inside app from outside one without full-reloading of the inside one. There is <BrowserRouter /> which uses Native History API.

I have tested the behavior on single app without any iframes.

When I click anchors in the app, React router doesn't refresh the whole app, and replaces parts of the app. In my case -- it's pagination.

I can call window.history.back() and it will not trigger page refresh. The same, I can do window.history.go(-1) and it will not trigger page referesh.

Then I decided what if I make window.history.pushState(null, null, 'page/2') and call window.history.go() -- page will be refreshed from scratch.

I can solve my task by replacing BrowserRouter by Router and exposing history object to window.ReactRouterHistory, but I think it's too much, when I can do window.history.back() without a page refresh.

Is it a bug? Why the page is fully refreshed by go(), but isn't when go(-1)? Is there a proper way to do this?

Thank you!

It sounds like you want this library to be something it's not. This library isn't meant to replace the browser's built-in history API. It's just a thin layer the router uses to communicate with the browser. But users are still free to call the browser's built-in methods however they wish.

In case 1, keep in mind the <base> tag is only supposed to be used for relative URLs in the current document. So history.push('/foo/bar') should not use the <base href> since it is an absolute path, but history.push('foo') should. This is why you don't see the <base href> in the first result, but you do in the second.

In case 2, there's really not much we can do. We would have to temporarily remove the <base> element from the page to prevent pushState from navigating to the new domain.

Would someone mind explaining briefly what the bug is? I've looked at it, but I can't say for sure I understand how and why Rollup is modifying the code here.

Is it because the warning() call is a no-op in production, so that else block is empty? What does Rollup do in that scenario?

Just a quick note here (already spoke with @gaearon about this on Twitter DM): This won't work with React Router v6+ because we don't expose context at all in the react-router package. The reason we did it in v5 was because changes in the context API required us to maintain a reference to the context object. But v6 uses hooks to access things on context instead of exposing the object itself.

I believe this may be fixed by listening for the add event (in addition to the change and unlink events) in the file watcher here, but I'm not familiar enough with the code to be sure. FWIW I cloned the repo and was going to fix the bug myself but I couldn't get all tests to pass locally.

<!-- ⚡️ katchow! We 💛 issues.

Please - do not - remove this template. Please - do not - skip or remove parts of this template. Or your issue may be closed.

👉🏽 Need help or tech support? Please don't open an issue! Head to https://gitter.im/rollup/rollup or https://stackoverflow.com/questions/tagged/rollupjs

👉🏽 Is this issue related to an official plugin? Please do not open an issue here, go to the plugins repository instead: https://github.com/rollup/plugins/issues

❤️ Rollup? Please consider supporting our collective: 👉 https://opencollective.com/rollup/donate -->

• Rollup Version: 2.23.0
• Operating System (or Browser): macos
• Node Version (if applicable): 14.3.0
• Link to reproduction (IMPORTANT, read below): https://github.com/mjackson/rollup-watch-dir

<!-- Issues without minimal reproductions will be closed! Please provide a link to one by:

1. Using the REPL at https://rollupjs.org/repl/, or
2. Using the REPL.it reproduction template at https://repl.it/@rollup/rollup-repro (allows full use of all rollup options and plugins), or
3. Provide a minimal repository link (Read https://git.io/fNzHA for instructions). These may take more time to triage than the other options.

For some bugs it this may seem like overkill but believe us, very often what seems like a "clear issue" is actually specific to some details of your setup. Having a runnable reproduction not only "proves" your bug to us but also allows us to spend all our effort fixing the bug instead of struggling to understand your issue. -->

Expected Behavior

I'm expecting a rebuild when a new file is added to a directory that was passed to this.addWatchFile.

Actual Behavior

New files do not trigger a rebuild.

<!-- Most issues can be expressed or demonstrated through the REPL or a repository. However, the situation may arise where some small code snippets also need to be provided. In that situation, please add your code below using Fenced Code Blocks (https://help.github.com/articles/creating-and-highlighting-code-blocks/) -->

One of the main things I did in the router repo to speed up testing and builds was to ditch lerna workspace run (or whatever it's called, can't remember). All the build + test infrastructure is able to work with the monorepo format, so e.g. I only have a single instance of Jest/Rollup running when I need to test/build. This eliminates startup time for spinning up individual processes, which can be significant in a repo with many packages.

I ran into this same issue today which really confused me for a while. I am trying to use an absolute path as my include value which works with minimatch, but doesn't work with createFilter.

f = createFilter('/a/b/**/*')
f('/a/b/c.js') // false

minimatch.match(['/a/b/c.js'], '/a/b/**/*') // ['/a/b/c.js']

IMO this could be fixed by adding support for absolute paths in include and exclude, so I'm 👍 on adding support for a leading /.

The workaround for me for now involves using path.relative just so I can get a relative path that will then be resolved correctly...

At the very least, a function parameter should not be considered to be "unused" if a parameter that comes after it is used. In that case, the "unused" parameter is actually serving a purpose by taking up a slot in the argument list.

function fun(a, b) {
  // The `a` parameter should not be considered "unused"
  console.log(b);
}