Is there a plan to add documentation to the README about how to use this feature? I got here from https://ideas.circleci.com/cloud-feature-requests/p/show-test-results-for-prospective-merge-of-a-github-pr but this PR is the only evidence that this exists here as far as I saw.

this path does not work in your tool:

M3 -1.48562e-06L0.113249 5L5.88675 5L3 -1.48562e-06Z

However it works as soon as you replace the two instances of -1.48562e-06 with -0.00000148562 .

M3 -0.00000148562L0.113249 5L5.88675 5L3 -0.00000148562Z

I am all but certain I already had 2.2.4.04 yesterday, but I tried again just to make sure with your link, same error (you should consider adding that last build number .04 in the diagnostic data logs?)

App Logs.txt App Settings.txt

As you said, my settings don't seem to indicate an issue like you described:

The progress bar now gets to about 2/3 full before failing, but it still fails consistently on 2.2.4 for me today:

App Logs.txt App Settings.txt

Quitting and restarting, opening the editor shows the recording just fine, but clicking "Done" there does not get the export to work like it used to after an app restart, so this is less usable for me now than the 2.2.2 revert has been where I can at least do that.

Hmm I see. Do you know of another plugin like that? Thanks for replying!

.someClass {
  padding: 20px;

  & h2 {
    width: 500px;
  }
}

This CSS should not be considered invalid by this plugin, but is. Many of the default rules in stylelint understand the meaning of this nesting operator &, I'm not sure how much work it would be to support from your plugin.

yeah, now that #99 is fixed, I get those too, using TS 4.0.2.

@mrmckeb there is no issue. I was just showing it working.

Seems to work great now in WebStorm. I will say, the editor did seem to take a while to load up the TS service when I added the plugin back in, I wonder how heavy this is.

Also the readonlys in the error message are a bit distracting, since they are repeated a lot. Was that a "just for correctness" piece or does it actually do something important? (idk how the internals of the plugin work)

@V-Gutierrez thanks for picking up the issue I created! 🎉

Same here. Glad to hear this is reproducible in a more-widely available IDE!

Sure, will do tomorrow.

The same error as the original post, with or without my patch and with or without your beta, unfortunately

replied over at https://github.com/mrmckeb/typescript-plugin-css-modules/issues/97#issuecomment-692285923

Hm, I tried the beta today and I get the same errors. I realize the reason the errors were gone when using my patch was probably because I was using the following in package.json: "typescript-plugin-css-modules": "https://github.com/ekilah/typescript-plugin-css-modules#patch-2",

That doesn't get 'built', so the directory in node_modules only has TS files. Maybe this was just preventing the editor from running the plugin at all, and it was failing silently.

I changed package.json from prepublishOnly to prepare as suggested by https://stackoverflow.com/questions/40528053/npm-install-and-build-of-forked-github-repo and installed my patch again, and was able to see errors still. So, I guess there is another issue causing this.

@fgblomqvist can you show screenshots of the plugin working in your JetBrains editor, so I can see more about what it adds for you? I haven't seen this plugin add anything to the default behavior already present in WebStorm yet. I know what it does for my coworkers in VSCode, though.

Regarding your workaround / fix to get things going:

Turns out that my IntelliJ couldn't properly find the plugin yesterday (we use lerna and it seems like you have to put the plugin the same package that the typescript is coming from, aka. the root package).

I'm not sure what package you're referring to or what you changed. This may or may not be relevant to my use case?

Thanks for getting back to me!

I rebased to get the TS 4.0 fix in #101, and updated the snapshots with yarn jest -u.

Without my patch:

With my patch:

Note that this just prevents the spammy errors in WebStorm; as far as I can tell, this plugin doesn't add any functionality in WebStorm. Without this plugin, WebStorm can already do this:

That last statement somewhat conflicts with #96 - the OP seems to get some use out of this plugin that I'm not seeing, but at least this PR fixes the errors.

thanks!

I am new and have no idea how debian's package updates system works, but I happen to be using lftp on a debian box. I came here looking if it would be possible to get 4.8.0+ on debian, apt-get only sees 4.7.1-1. Any advice would be appreciated!

Thanks for your valuable insight.

So is having clear expectations and instructions on a project that anticipates public input from people unfamiliar with the codebase. Not getting a reply in 3 weeks isn't a good incentive to go diving into the various test suites to fix CI either.

But I'm not here to complain, I'm just trying to report an issue and help solve it. I don't think the subtle condescension about the importance of doing this and that are productive or earned.

If you don't mind posting the set of commands necessary to do what you're asking for, I can do that next time I have some time. You neglected to include instructions.

I did nothing like that no. I don't see any instructions on the repo's markdown files describing how to do what you are implying is necessary. Let me know and I can try those things.

BenQ monitor here. Gifs fail now immediately after restarting the app too on the latest update, which means it's completely unusable now.

Awesome 🥳 Thanks for your help debugging & getting this live!

sure, solved, and thanks!

Personally I think the test is harder to read / isn't as obviously testing the behavior it is testing this way, and it doesn't test the return value of flags() anymore.

@wavebeem alright, I think this should be complete. I added the changelog entries, but I guess it's a bit weird since idk if you'll actually release it with that version number. Let mek now if this needs to be squashed or if you'll do that, etc.

ESLint doesn't like these flags. And this override doesn't work if you define the Regexp like /a/gimuy, you have to use the new Regexp constructor, apparently.

If you give the closestTo function an empty list of dates, it returns undefined. This is not represented in the TS typings.

Heroku currently copies our entire repo from git, builds the production app, and then copies the entire directory (including the consumed source files etc) to the machine(s) serving the app.

We don't need most of that stuff in there, and now (mostly since node_modules has gotten quite large, but also other things, like our source images/svgs are there twice) it has gotten big enough (>300MB) that Heroku is starting to warn us about the size.

heroku-buildpack-post-build-clean takes a .slug-post-clean file and deletes things you don't need in there after the build process. My fork gets rid of some errors because comments in the file weren't being ignored previously.

Heroku currently copies our entire repo from git, builds the production app, and then copies the entire directory (including the consumed source files etc) to the machine(s) serving the app.

We don't need most of that stuff in there, and now (mostly since node_modules has gotten quite large, but also other things, like our source images/svgs are there twice) it has gotten big enough (>300MB) that Heroku is starting to warn us about the size.

heroku-buildpack-post-build-clean takes a .slug-post-clean file and deletes things you don't need in there after the build process. My fork gets rid of some errors because comments in the file weren't being ignored previously.

Pretty simple, the package.json should support TS 4.0 which was just released. I would submit a PR to make the change, but I'm not sure what you'd prefer to use, e.g. ^3.0.0 || ^4.0.0 would work, or >= 3.0.0. Depends on your preferences I guess.

(TS doesn't use semantic versioning, so 3.9 -> 4.0 is no different than 3.9 -> 3.10 to them.)

Sure, I added that instead. I agree the way flags worked before was a bit messy, and I wasn't aware of these other flags before.

I tested the 5 boolean flags in my production environment, it looks like re.unicode doesn't work properly on these versions of Edge:

Using this regex: /[0-9]/gimuy I logged this:

    {
        regexStr: '' + regex,
        global: regex.global ?? 'undefined var',
        ignoreCase: regex.ignoreCase ?? 'undefined var',
        multiline: regex.multiline ?? 'undefined var',
        unicode: regex.unicode ?? 'undefined var',
        sticky: regex.sticky ?? 'undefined var',
      }

and got this:

Mostly just noting this for you if it ever comes up. I doubt it will!

As for the tests and whatnot, sure, I can do some of that maybe later in the week. As a suggestion - the README on contributing should mention the linter and/or test coverage expectations. I'd add them but I don't know what the expectations are 😄

Forgive me if I'm mistaken, I am new to reading this codebase, but:

https://github.com/heroku/heroku-buildpack-nodejs/blob/77b953be1a71cff4dfcc956e53232f8433d74233/lib/cache.sh#L47-L58

Does this code also need to be changed to read the new env var instead?

I've put the below results of my testing in a PR (https://github.com/jneen/parsimmon/pull/304). It does seem like the literal string "undefined" is rendered to the regex when it is stringified on these old browser versions.

Fixes https://github.com/jneen/parsimmon/issues/303

Summary of problem

We saw these reports in our bug tracker:

Error unsupported regexp flag "n": /[0-9]/undefined 
    node_modules/parsimmon/build/parsimmon.umd.min.js:1:6716 Anonymous function
    node_modules/parsimmon/build/parsimmon.umd.min.js:1:6560 K
    node_modules/parsimmon/build/parsimmon.umd.min.js:1:11055 Anonymous function
    node_modules/parsimmon/build/parsimmon.umd.min.js:1:348 r
    node_modules/parsimmon/build/parsimmon.umd.min.js:1:407 Anonymous function
    node_modules/parsimmon/build/parsimmon.umd.min.js:1:199 Anonymous function
    node_modules/parsimmon/build/parsimmon.umd.min.js:1 Anonymous function
    webpack/bootstrap:25:3 __webpack_require__
    https://mywebsite.com/static/js/main.abc.js:1:123 Anonymous function
    webpack/bootstrap:25:3 __webpack_require__

These errors were coming from MS Edge versions 15-18, but I couldn't find a way to download and install that version to test for myself. It seemed like that browser was rendering the literal string "undefined" at the end of regular expressions when they were printed as strings.

Research

To get some data from our prod environment, I added the following code to parsimmon:

function flags(re) {
  var s = "" + re;
  var fs = s.slice(s.lastIndexOf("/") + 1);
  if (fs === "undefined" || fs === undefined) {
    // eslint-disable-next-line no-console, no-undef
    console.warn('Flags of regex were undefined.', {re: re, s: s, fs: fs, typeofFs: typeof fs})
    return ""
  }
  return fs
}

and got this output from Edge versions 17 and 18:

{
  "re":{},
  "s":"/[0-9]/undefined",
  "fs":"undefined",
  "typeofFs":"string"
}

I also added this above var digit = regexp(/[0-9]/).desc("a digit"); so it would run when parsimmon is imported in my project:

var reTest = new RegExp(/[0-9]/)
var reWithFlagTest = new RegExp(/[0-9]/i)
var strTest = new RegExp("[0-9]")

// eslint-disable-next-line no-console, no-undef
console.warn('Debugging regexes:', {
  re: {
    asString: '' + reTest,
    flagsDefined: typeof reTest.flags === 'string',
    flags: reTest.flags,
  },
  reWithFlag: {
    asString: '' + reWithFlagTest,
    flagsDefined: typeof reWithFlagTest.flags === 'string',
    flags: reWithFlagTest.flags,
  },
  str: {
    asString: '' + strTest,
    flagsDefined: typeof strTest.flags === 'string',
    flags: strTest.flags,
  },
})

and got this output from Edge versions 17 and 18:

{
  "re":{
    "asString":"/[0-9]/undefined",
    "flagsDefined":false
  },
  "reWithFlag":{
    "asString":"/[0-9]/undefined",
    "flagsDefined":false
  },
  "str":{
    "asString":"/[0-9]/undefined",
    "flagsDefined":false
  }
}

Fix

To fix this, we can detect undefined as the flags string and overwrite it.

It seems literally impossible to find a way to install this ancient version of Edge, I can't find an installer anywhere... 😬

We made a bunch of dependency updates all at once (upgrading webpack and other things), so there aren't any guarantees I can give from my end like "this was all I changed" unfortunately. But we didn't change anything about how we use Parsimmon.

I think testing on Edge 16/18 would be the best next step; if the VMs don't allow it, let me see if my old windows 7 machine gathering dust can install it.

Are you 100% sure your application code hasn't changed? If you somehow did /[0-9]/ + someVar and someVar was undefined, you would see the result in question ("/[0-9]/undefined").

The text in the error message in our bug tracker ("unsupported regexp flag") matches 100% with the string here: https://github.com/jneen/parsimmon/blob/cb77d09f900bb292389f0cf4870126bb5aa8b8d9/src/parsimmon.js#L466

not to mention the call stack being from the parsimmon library, and also parsimmon creates this regex: https://github.com/jneen/parsimmon/blob/cb77d09f900bb292389f0cf4870126bb5aa8b8d9/src/parsimmon.js#L1334

So you're saying /[0-9]/ turns into "/[0-9]/undefined" when it's turned into a string in Edge 18?

That's what the Bugsnag error reports suggest, anyway. I am surprised by this as well. I wish I could confirm it, maybe I can with the VM link you suggested.

The flags function is only there because regexp.flags doesn't exist in old browsers.

Yeah, I noticed that on the MDN docs/caniuse. Specifically it seems to be missing on.... IE/old Edge. -_-

Are you interested in contributing a PR to fix this? It seems like you could do a check like if (re.flags !== undefined) return re.flags right at the top so we can just use the built-in flag property if it exists.

I would be willing to, but I would feel bad about making a PR for something I can't test. I was hoping maybe you had access to a machine that could prove the theory re: the cause. Again maybe I'll have time to do something with a VM to help out.

After reading the code here I can't see what else could cause it, since your error message prints the regex here:

https://github.com/jneen/parsimmon/blob/cb77d09f900bb292389f0cf4870126bb5aa8b8d9/src/parsimmon.js#L466

My only remaining thought is that I wasn't seeing these errors before I upgraded to the latest version, so I was wondering if you had ideas on any recent behavior changes that could have caused this. I haven't checked whether or not I had users on that browser version before my upgrade to 1.15.0, but I presume I did, since these errors showed up within an hour or two of the upgrade.

Error unsupported regexp flag "n": /[0-9]/undefined 
    node_modules/parsimmon/build/parsimmon.umd.min.js:1:6716 Anonymous function
    node_modules/parsimmon/build/parsimmon.umd.min.js:1:6560 K
    node_modules/parsimmon/build/parsimmon.umd.min.js:1:11055 Anonymous function
    node_modules/parsimmon/build/parsimmon.umd.min.js:1:348 r
    node_modules/parsimmon/build/parsimmon.umd.min.js:1:407 Anonymous function
    node_modules/parsimmon/build/parsimmon.umd.min.js:1:199 Anonymous function
    node_modules/parsimmon/build/parsimmon.umd.min.js:1 Anonymous function
    webpack/bootstrap:25:3 __webpack_require__
    https://mywebsite.com/static/js/main.abc.js:1:123 Anonymous function
    webpack/bootstrap:25:3 __webpack_require__

Seeing the above a few times in my error tracker for Windows 10 devices running Edge 16 and Edge 18 (very old, non-chromium builds of the Edge browser).

Running the latest parsimmon at 1.15.0. We just recently upgraded from 1.12.0 and I hadn't noticed these errors previously, if that's helpful.

The error message is a bit odd, but my guess is that RegExp on these versions of Edge don't support flags very well. It looks to me after reading the source for parsimmon that the regep is literally presenting as the string "/[0-9]/undefined" when flags converts it to a string:

https://github.com/jneen/parsimmon/blob/cb77d09f900bb292389f0cf4870126bb5aa8b8d9/src/parsimmon.js#L696-L699

I tried to see if I could install that version on my Windows 10 machine, but I guess Microsoft has made that difficult to do side-by-side with the new Edge, so I wasn't able to finish that try.

I mostly only bring this up because your README claims to support IE7+. I think this case would be not too hard to detect, if you're willing to test it and support these old Edge versions.

Glad to help. Sorry it took a while to try again. Let me know if more testing becomes useful, I'll do what I can. Love the tool, so I want it to work nicely again :)

I guess I should clarify, it seemed to resolve things, but maybe the CI failure means that it was just broken in a different way? Unclear. I'll let you tell me, I am just observing symptoms :)

Feature motivation

I have a project that is on the webpack 5 beta, and this plugin's types show some errors in my editor's TS language service window. I am wondering if this plugin has a branch or anything yet dedicated to webpack 5 support.

Error:(3, 61) TS2694: Namespace 'exports' has no exported member 'Plugin'.
Error:(11, 58) TS2694: Namespace 'exports' has no exported member 'compilation'.

Feature description

It appears some of the exports from Webpack have changed names / etc. (see the above screenshot). I guess they'd have to be changed in this project?

I think this is user error. I updated webpack but not @types/webpack. I'll close this out!

@mrmckeb Sorry it took so long to try this out, been busy!

Yes, that change does seem to fix the issue! It's annoying to test because it seems like I have to quit/restart Webstorm for it to decide to consume the changes in my package.json 😛 , but I confirmed the hundreds of errors disappeared with this change.

Added that to a PR: https://github.com/mrmckeb/typescript-plugin-css-modules/pull/100

Fixes #97

This avoids errors in the Webstorm IDE's TypeScript console.

Fixes #97

Oh, this is based on master I think, sorry

Fixes #97

Occurred again for me on 2.2.2

If you experience this issue, please send us your diagnostics data (library window > bottom-right menu button). App Logs.txt App Settings.txt

When the export fails don't quit the app and try: a. Open any earlier successful recording in the editor. Do you see the image or does it come out black? Can you play it?

No. They all look like this. The timeline on some seems to render a few frames, but regardless they won't play.

b. Press Done to re-export it, does the export succeed? To be clear, it here is a previously-working export, as in (a) above.

No. At first my previously-working export hung like this after clicking Done:

After 20 seconds or so, it eventually changed to the failure state, just like the new recordings do:

c. Record a short video with the standard screen capture and import it into Gifox. Does the conversion succeed?

The video worked (cmd+shift+6 to choose the Mac native video recording since I use 5 for Gifox) but dragging it onto the Gifox menu bar and dropping it in the conversion box failed. The progress bar did move quickly at first but failed at about the 70% mark.

If you use external monitor: disconnect it and relaunch the app. Make a quick recording, reconnect it and make another recording. Disconnect it and make another recording. Did anything go wrong?

Nothing went wrong. I did several sleeps and disconnects to try and reproduce it, but it just won't reproduce for me.

Experiencing issue Disconnect monitor Relaunch Gifox Record ✅ Reconnect monitor Record ✅ Disconnect monitor Record ✅ Connect monitor Sleep, wait 20 seconds Wake Record ✅ Disconnect monitor Record ✅ Sleep, wait 20 seconds Wake Record ✅ Connect monitor Record ✅

None of these steps ran into issues. And yet, it happens for me all the time, somehow. Maybe it has more to do with how long the app is running? I basically never shut my laptop down, like once a month. Usually it just sleeps. Or, maybe I didn't sleep long enough (the computer didn't lock, it just went to sleep and woke up immediately when I pressed a key, no login screen required, which usually happens after 5min of sleep w/ my settings)

If you have any additional details or comments, please let us know!

Battery: 63%, charging (don't think this is relevant, happens all the time at 100% charging) External monitor: 4K over Thunderbolt 3 and via a dock, recently plugged in Sleep: recently woken from sleep

@BigsonLvrocha thank you for that idea re: why-is-node-running! In my case that tool showed me that redux-state-sync was being initialized in tests, which has an infinite loop to listen for Redux updates in it. --detectOpenHandles did not output anything for me, either.

Ready to merge

Great, thank you!

As described in https://github.com/DefinitelyTyped/DefinitelyTyped/pull/46480 , the BroadcastChannel package will correctly default the options you pass to it if undefined is passed as the options object. However, using null results in a TypeError:

TypeError: Cannot read property 'webWorkerSupport' of null
          at fillOptionsWithDefaults (/Users/.../node_modules/redux-state-sync/node_modules/broadcast-channel/dist/lib/options.js:12:22)
          at new BroadcastChannel (/Users/.../node_modules/redux-state-sync/node_modules/broadcast-channel/dist/lib/broadcast-channel.js:23:55)
          at Object.createStateSyncMiddleware (/Users/.../node_modules/redux-state-sync/dist/syncState.js:131:19)
          at Object.<anonymous> (/Users/.../src/redux/store.ts:37:31)

I can't run the tests nor the linter locally for some reason, so I didn't add any tests at first. But since the bots demand them anyway, I tried to add one.

BroadcastChannelOptions is more specific than object, and also null is incorrect - it is only allowed to be undefined in broadcast-channel, which is covered by the ? already:

https://github.com/pubkey/broadcast-channel/blob/8d2ee79aad2780e9df3ab4e1386548a9a323f8bb/dist/lib/options.js#L9 https://github.com/pubkey/broadcast-channel/blob/8d2ee79aad2780e9df3ab4e1386548a9a323f8bb/types/broadcast-channel.d.ts#L45-L46

Please fill in this template.

• [x] Use a meaningful title for the pull request. Include the name of the package modified.
• [x] Test the change in your own code. (Compile and run.)
• [ ] Add or edit tests to reflect the change. (Run with npm test.)
• [x] Follow the advice from the readme. well actually I can't run the linter nor the tests locally, they all produce errors unrelated to this project for me
• [x] Avoid common mistakes.
• [x] Run npm run lint package-name (or tsc if no tslint.json is present). this also errors out with errors from other projects

Select one of these and delete the others:

If changing an existing definition:

• [x] Provide a URL to documentation or source code which provides context for the suggested changes: see above
• [ ] If this PR brings the type definitions up to date with a new version of the JS library, update the version number in the header.
• [ ] Include tests for your changes
• [ ] If you are making substantial changes, consider adding a tslint.json containing { "extends": "dtslint/dt.json" }. If for reason the any rule need to be disabled, disable it for that line using // tslint:disable-next-line [ruleName] and not for whole package so that the need for disabling can be reviewed.

Somewhat unrelated, but there are some issues I'm experiencing with this plugin in WebStorm, xposting here. https://github.com/mrmckeb/typescript-plugin-css-modules/issues/97