primordic/IssueDupesLite huggingface dataset:
Repository: TryQuiet/quiet

Issue #918: App becomes laggy if you stay in one channel on Android 13
Created: 2022-09-14T12:35:36Z
On a Pixel 6 the app becomes too laggy for regular use. Sometimes the app gets so laggy that text entry becomes impractical. There is a 10 or 20 second delay between typing and the text appearing.
Steps to reproduce:
0. Run Quiet on Android 13

Send a few messages in general channel, without switching to other channels.

Expected: I can still type with no lags
Actual: app is too laggy to type text and send a message.
UPDATE: I just realized that by navigating out of a channel and navigating back in I can solve the problem. This is consistent with what @siepra was seeing in the logs; it's a UI problem e.g. with lazy loading.
logs-adb-app-slow.txt

Duplicate issue #987: Extreme lag (minutes) switching channels while syncing
Created: 2022-10-26T13:40:56Z
On Lisa's device (pixel 4a, Android 13) the app became unresponsive for:

Opening a channel from the channel list
Going back to the channel list from a channel
Clicking in text entry field and opening keyboard

This was after Lisa upgraded after not using the app for some time. So message re-verification or message syncing might have been slowing things down. This could be a duplicate of #891 and #890

Closing comment (2022-11-17T13:33:48Z): I think we should assume this is related to #918 and #891 unless it keeps happening.
Repository: TryQuiet/quiet

Issue #765: User should be able to switch channels
Created: 2022-08-03T19:43:58Z
A user should have a homescreen where they can see a list of channels and navigate in/out.
Designs are here: https://www.figma.com/file/y8h6w8PYR9jyI3zjYHL9Cl/Mobile?node-id=456%3A18828
Acceptance criteria

Users see a list of all channels when they open app
Users can click any channel item to get to channel view
Users can navigate back to this list from channel view by swiping left.
Channel items are tall enough to be easily clickable

Channel item shows:

channel name
channel "thumbnail" (just first two letters of channel name against dark grey)
unread status

Not requirements:

Sorting
Latest message
Latest message time
DMs (obv) etc.
Search
title bar on home screen or messages view (swipe is sufficient for navigation)

Note on unread status:
Unread status should show with "1+" if it's hard to know the # of unread or (if it's easy) the number of unread messages.

Duplicate issue #362: Switching channels on mobile
Created: 2022-03-18T09:08:28Z
We can add sidebar to the application or do it slack-way (with separate, main screen with the list of communities, channels, online users etc.)

Closing comment (2022-08-16T10:18:46Z): Duplicate of #765
Repository: TryQuiet/quiet

Issue #776: Notifications are minimally working (Android)
Created: 2022-08-03T20:38:02Z
It will be difficult to get notifications working perfectly, but we should get started.
Acceptance criteria: if Quiet is connected and it receives a message, a notification should display that shows the message contents and the message sender.

Duplicate issue #363: Display notifications about incoming messages when the app process is running (Android)
Created: 2022-03-18T09:10:09Z

Closing comment (2022-08-16T10:20:43Z): Duplicate of #776
Repository: TypeScriptToLua/TypeScriptToLua

Issue #231: Falsey values?
Created: 2018-10-10T22:08:23Z
There's a big discrepancy between lua and js regarding 'falsey' values. In lua, only 'nil' and 'false' are will evaluate as false, while in js there are a number of values that will, including the number zero (0) and empty strings ("").
It seems like this is something that should be handled when transpiling since this statement will currently evaluate as true in lua but false in js:
if (0) { /* do something */ }
But, this could introduce a lot of undesirable overhead, so I'm curious what thoughts are around this.

Is it something that should be handled or should users be aware that the rules are different?
If handled, should there be a compiler option to disable it, to improve performance?
If not handled maybe a compiler warning when non-boolean expressions are used in conditions?

Duplicate issue #261: Using Lua's length operator "#"
Created: 2018-10-20T18:46:10Z
Right now we are using # to translate Array.length.
However Lua's # behaves slightly different if a array containts "gaps"
local x = {1,2}
x[5] = 12
print(#x) -- prints 2 (executed in https://www.lua.org/cgi-bin/demo)
var arr = [1, 2];
arr[5] = 12;
console.log(arr.length); -- logs 6
Right now length is the only place where we use #,
but we were thinking about using # in forOf translation aswell #260.
Here are some possible solutions to the problem:


Leave it to the programmer not to have gaps in arrays and use # in transpiled lua.


Add a custom array type to lualib that patches __index and __newindex to keep track of the array/table length. (Probably wont work if arrays are passed from native lua)


Add an transpiler options called "safe mode" where we replace # with a custom function that gets the length by iterating with pairs. In unsafe mode just keep using #.

Closing comment (2018-10-23T12:07:04Z): Im fine with treating the default the same as #231. But I think we should really make a compilerOption that enables the use of our own "safe arrays", similar to what @Perryvw mentioned above.
Moved to #262 and #263
Repository: TypeScriptToLua/TypeScriptToLua

Issue #433: Support typescript transformers
Created: 2019-02-20T06:13:17Z
Required for a simple resolution of #178.
Covers many use cases of #179.

Duplicate issue #593: feature request: Support ttypescript
Created: 2019-05-25T10:00:16Z
https://github.com/cevek/ttypescript

Closing comment (2019-05-26T16:05:40Z): Closing since it's mostly the same as #433. I haven't yet decided on config schema, but now it's compatible with ttypescript.
Repository: TypeScriptToLua/TypeScriptToLua

Issue #1317: Prevent compilation when local variable limit is hit
Created: 2022-07-27T19:23:49Z
Today, in Discord, we discussed the possibility of TSTL taking extra steps to handle the case of a TSTL program with over 200 local variables.
Right now, it sounds like Perry just wants to keep things as is, given that there are tradeoffs with either option.
However, everyone can agree that run-time errors are terrible - the whole point of using TSTL in the first place is to stop run-time errors. With that in mind, can we make TSTL keep a counter of the current scope's local variables, and then refuse to compile (or throw a warning) if the counter reaches 200? (Or maybe even 190, to be a little on the safe side.)
This would give the end-user the chance to refactor their program long before running into any issues in production!

Duplicate issue #1507: "too many local variables" when working with generated code
Created: 2023-10-20T00:29:57Z
Working with code generated via another language to JS/TS can generate a lot of intermediate locals. The standard Lua interpreter caps out at 200.
An MRE:
() => {

let [
    _001, _002, _003, _004, _005, _006, _007, _008, _009, _010,
    _011, _012, _013, _014, _015, _016, _017, _018, _019, _020,
    _021, _022, _023, _024, _025, _026, _027, _028, _029, _030,
    _031, _032, _033, _034, _035, _036, _037, _038, _039, _040,
    _041, _042, _043, _044, _045, _046, _047, _048, _049, _050,
    _051, _052, _053, _054, _055, _056, _057, _058, _059, _060,
    _061, _062, _063, _064, _065, _066, _067, _068, _069, _070,
    _071, _072, _073, _074, _075, _076, _077, _078, _079, _080,
    _081, _082, _083, _084, _085, _086, _087, _088, _089, _090,
    _091, _092, _093, _094, _095, _096, _097, _098, _099, _100,
    _101, _102, _103, _104, _105, _106, _107, _108, _109, _110,
    _111, _112, _113, _114, _115, _116, _117, _118, _119, _120,
    _121, _122, _123, _124, _125, _126, _127, _128, _129, _130,
    _131, _132, _133, _134, _135, _136, _137, _138, _139, _140,
    _141, _142, _143, _144, _145, _146, _147, _148, _149, _150,
    _151, _152, _153, _154, _155, _156, _157, _158, _159, _160,
    _161, _162, _163, _164, _165, _166, _167, _168, _169, _170,
    _171, _172, _173, _174, _175, _176, _177, _178, _179, _180,
    _181, _182, _183, _184, _185, _186, _187, _188, _189, _190,
    _191, _192, _193, _194, _195, _196, _197, _198, _199, _200,
    _201
] = Array(201); 

}
But in generated code these will often all have purposes (not just generated from an array destructuring).

Closing comment (2023-10-20T00:57:38Z): duplicate of #1317?
Repository: TypeScriptToLua/TypeScriptToLua

Issue #725: Inherited accessors break when base is type-erased
Created: 2019-09-25T12:06:25Z
When extending type-erased bases with accessors, the accessors are called with incorrect this.
Example
const A = class {
    get value(): this {
        return this;
    }
} as any;

class B extends A {
    
}

const b = new B();
console.assert(b.value === b); // boom

Duplicate issue #728: Inheritance breaks toString()
Created: 2019-10-01T07:22:19Z
Code
class A {
    public toString() {
        return "A";
    }
}

class B extends A { }

console.log(new B());
Expected output
A

Current output
table: 0x2d

Closing comment (2019-10-01T07:27:26Z): This issue is related to #725, as we currently ignore existing metamethods of base classes that get lost on inheritance (Lua uses rawget to find metamethods, ignoring the __index table). One general solution might be to query the base class metatable and forward metamethods to the new class. Another solution would be to add the metamethods in the constructor as proposed in #724.
Repository: TypeScriptToLua/TypeScriptToLua

Issue #489: Array detection fails on constrained generics
Created: 2019-03-21T17:57:53Z
Input
function f<A extends any[]>(a: A){
  a.forEach(v => console.log(v));
}
Current Result
f = function(self, a)
    a:forEach(function(____, v)
        return print(v);
    end);
end;
Expected Result
f = function(self, a)
    __TS__ArrayForEach((a), function(____, v)
        return print(v);
    end);
end;

Duplicate issue #544: Tuple/ Array bug
Created: 2019-05-01T09:54:03Z
https://gitlab.com/the-language/the-language/blob/cb8acab436254a0945828206ea6c085506af2992/core/pure/typescript/lang.ts#L223
https://gitlab.com/the-language/the-language/blob/cb8acab436254a0945828206ea6c085506af2992/core/pure/lua/lang.lua#L182

Closing comment (2019-05-01T23:48:15Z): Duplicate of #489
Repository: TypeScriptToLua/TypeScriptToLua

Issue #221: Issues with non-lua operators on properties of objects
Created: 2018-10-07T19:52:45Z
Operators such as '+=', '++', etc... can be broken easily right now.
Example 1:
declare function foo(): number;
declare const a: number[];
a[foo()]++;
=>
a[(foo())+1] = (a[(foo())+1]+1);
Here foo() will be called multiple times, producing possibly different values each time or having other undesired side-effects.
Example 2:
declare function bar(): number[];
let f = bar()[0]++;
=>
local f = (function()
    local __originalValuebar()[(0)+1]0 = bar()[(0)+1];
    bar()[(0)+1] = (bar()[(0)+1]+1);
    return __originalValuebar()[(0)+1]0
end
)();
This one won't even compile in lua.
These kinds of issues could be solved by detecting if the value being operated on is a property and caching the object and index parts before performing the operation. This could be wrapped in specialized polyfill functions like the ternary operator is:
function __TS__PropertyPostInc(o, i)
    local original = o[i]
    o[i] = o[i] + 1
    return original
end

--Example 1
__TS__PropertyPostInc(a, foo())

--Example 2
local f = __TS__PropertyPostInc(bar(), 0)

Duplicate issue #276: Post-incrementing properties generates invalid identifiers
Created: 2018-11-08T10:16:09Z
Post-incrementing properties or array values generates invalid lua identifiers
class Test {
	lastId = 0;

	constructor() {
		log(this.lastId++);
	}
}
The generated code looks like this
log((function()
        local __originalValueself.lastId0 = self.lastId;
        self.lastId = (self.lastId+1);
        return __originalValueself.lastId0;
 end
A similar situation happens when trying to access a variable using bracket notation
let data = {value : 0};
log(data['value']++);
Generated code:
local data = {value = 0};
log((function()
    local __originalValuedata["value"]0 = data["value"];
    data["value"] = (data["value"]+1);
    return __originalValuedata["value"]0
end
)());

Closing comment (2018-11-11T00:38:43Z): I believe this is the same as #221 which is fixed by #241.
Repository: TypeScriptToLua/TypeScriptToLua

Issue #963: Move annotations to language extensions where possible
Created: 2021-01-05T09:21:07Z
Now that we have language extensions, we can move some of the more hacky annotations to language extensions instead.
Some of the annotations that can be moved:

@forRange
@luaIterator
@luaTable(?)
@vararg

Did I miss any?
@tupleReturn is already moved, should we deprecate the annotation at some point?

Duplicate issue #580: Explore using custom types instead of tuple and iterator decorators
Created: 2019-05-15T11:48:25Z
type LuaIterable<T> = Iterable<T> & { __luaIterable: never };
type LuaTuple<T extends any[]> = T & { __luaTuple: never };
Solution for #579. Also could simplify implementation.

Closing comment (2021-03-06T20:01:55Z): Added with language extensions Lua in #821 #981 #516
Remaining annotations are tracked in #963
Repository: TypeScriptToLua/TypeScriptToLua

Issue #973: Proposal: Lualib override plugins
Created: 2021-01-29T20:03:34Z
In the last 2 weeks we received two requests for the ability to modify lualib output with plugins. One for supplying an environment-specific implementation of __TS__New, and another for a specialized ArrayForEach implementation for an environment's special tables.
Other use cases for overriding lualib functions might be using computation/memory/garbage optimized versions of lualib functions.
I think this is a 'quick win' as it seems relatively simple to implement this as follows:
Add a record to the plugin interface that allows supplying a string for a lualib feature:
export interface Plugin {
    /**
     * An augmentation to the map of visitors that transform TypeScript AST to Lua AST.
     *
     * Key is a `SyntaxKind` of a processed node.
     */
    visitors?: Visitors;

    /**
     * A function that converts Lua AST to a string.
     *
     * At most one custom printer can be provided across all plugins.
     */
    printer?: Printer;
+
+    /**
+     * Provide a custom string that will be emitted as implementation for a lualib feature.
+     */
+    lualib?: Partial<Record<LuaLibFeature, string>>
}
Then a plugin could look like this:
const plugin = {
    lualib: {
        [LuaLibFeature.Delete]: `
            function __TS__Delete(target, key)
                target[key] = nil
            end
        `
    }
}
Or even:
const plugin = {
    lualib: {
        ...garbageCollectorOptimizedLualibCollectionFromNpmPackage,
        ...lualibFunctionsForEnvironment
    }
}
We then pass these plugins to the printer and override the lualib methods it wants to emit.
What I'm not sure about yet is if these should be supplied as Lua string or something else (TS/Lua AST/TS AST). Also leaving in the function header like I did in the example could potentially lead to typos and other issues, although we should easily be able to put in a diagnostic for that.

Duplicate issue #1502: Support recompile lualib with custom plugin?
Created: 2023-10-17T11:06:16Z
Here is the case, I want to implement a proxy for array in luajit environment with __index and __newindex that read write data in another table.
However, luajit which is lua5.1 doesn't support __len __ipair metamethod, and length operator #, global next function, global ipairs function would return wrong result on proxy.
Then I come up with an idea that write a printer plugin that print  # next ipairs into some custom implementation, but this plugin would ignore code in lualib.
I think the problem is, the plugin doesn't give user enough power to modify the compilation process, since lualib are already compiled before plugin taking over.

Closing comment (2023-10-17T19:55:02Z): Sounds like this is a duplicate of #973, I still think this would be a good idea to do. However, the design is not yet clear to me, and we need to decide on what the interface for this should be.
Repository: TypeScriptToLua/TypeScriptToLua

Issue #1212: Add warning diagnostic when trying to use if statement expression that always evaluates to true in Lua
Created: 2022-01-31T13:30:27Z
Maybe i missed something in the documentation or issues, but i cannot find anything about the difference in falsy values. The most obvious one being "0", and the transpilation of this code:

As far as i can tell, this should not print the value because 0 is false in typescript. But it will print it, because 0 is true in lua!
Is this intended? Am i wrong and 0 is actually true in typescript as well? I am quite confused right now

Duplicate issue #1243: The difference between typescript and Lua of implicit conversion Boolean
Created: 2022-03-30T02:04:54Z
When I wanted to know that a variable was literally empty, I encountered a strange bug.After investigation, it is found that it is caused by different language characteristics.
when I write code like:
const a = SomeFunction();
if(a){
    Do Some Thing;
}
I means a is a not literally empty, not null,not false,not zero,not empty string .etc
but
if(a) then
 Do Some Thing;
end
meas a is not nil.
This may have an unknown consequence
maybe  “if(expr)” can transform to "if(a~=nil and a ~= 0 and a ~='' and a ~= false)"?

Closing comment (2022-04-02T12:12:16Z): Intentional tstl behaviour, closing this as duplicate of #1212
Repository: TypeScriptToLua/TypeScriptToLua

Issue #151: Add Object static methods
Created: 2018-07-19T13:47:01Z
Object.keys
 Object.values
 Object.hasProperty

Duplicate issue #180: Add Object.keys/entries/values to lualib
Created: 2018-08-21T20:50:22Z

Closing comment (2018-09-05T11:50:06Z): duplicate of #151
Repository: TypeStrong/ts-loader

Issue #267: Tries to compile sources that are not supposed to be loaded
Created: 2016-08-20T13:33:17Z
Webpack 2 and TS2 beta
ts-loader tries to compile even source that should not be loaded by webpack. Is it expected behaviour?

Duplicate issue #656: ts-loader executing files not in Webpack Dependency Graph 
Created: 2017-10-17T06:24:52Z
From my understanding, the dependency graph generated by Webpack will only contain files imported through the entry file. Other files aren't inspected. However, when I build a Typescript project with webpack/ts-loader, files, and files in subdirectories, in the same folder as the entry file are being inspected by the build process even though they aren't imported anywhere.
Say for example, I have a typical webpack/typescript project. In the src folder, alongside entry.ts, I place a notInDependencyGraph.ts file with just some gibberish like 'ajlkajdflkajsdlf', which is not imported anywhere.
Webpack outputs:
ERROR in ~/test/src/scripts/notInDependencyGraph.ts
(1,1): error TS2304: Cannot find name ajlkajdflkajsdlf
Now when dealing with babel-loader in the past, webpack wouldn't even touch that file. Is this just a consequence of ts-loader, though awesome-typescript-loader has the same issue, or is it a consequence of my misunderstanding of Webpack's inner workings, which is indeed shallow.

Closing comment (2017-10-17T07:31:37Z): Closing as duplicate of #267
Essentially this is intended behaviour but we're open to PRs that introduce alternative behaviour that will be opt-in only (i.e. users would need to specify a ts-loader option to trigger this behaviour)
Repository: TypeStrong/ts-loader

Issue #1061: Can't use nullish coalescing operator with TypeScript 3.8.2
Created: 2020-02-25T12:54:34Z
Expected Behaviour
With TypeScript 3.8.2 I can't use the nullish coalescing operator ?? anymore.
Actual Behaviour
I'm getting the error message
Module parse failed: Unexpected token (36:49)
File was processed with these loaders:
 * ./node_modules/ts-loader/index.js
You may need an additional loader to handle the result of these loaders.
Steps to Reproduce the Problem
Just use const foo = bar ?? '' in your codebase. With TypeScript 3.7.5 everything works fine

Duplicate issue #1065: Not compatible with 3.83
Created: 2020-03-11T09:43:45Z
https://github.com/TypeStrong/ts-loader/tree/master/examples/vanilla
package.json
{
  "name": "vanilla",
  "main": "index.js",
  "version": "1.0.0",
  "scripts": {
    "build": "webpack --mode production",
    "start": "webpack-dev-server --mode development --progress --color"
  },
  "devDependencies": {
    "ts-loader": "^6.2.1",
    "typescript": "^3.8.3",
    "webpack": "^4.42.0",
    "webpack-cli": "^3.3.11",
    "webpack-dev-server": "^3.10.3"
  }
}


index.js
let a = 1 ?? 2;

error:
ERROR in ./src/index.ts 1:11
Module parse failed: Unexpected token (1:11)
File was processed with these loaders:
 * ./node_modules/ts-loader/index.js
You may need an additional loader to handle the result of these loaders.
> let a = 1 ?? 2;
| 
i ｢wdm｣: Failed to compile.

Closing comment (2020-03-11T10:54:18Z): Duplicate of #1061
Set you target something lower than ES2020
Repository: TypeStrong/ts-loader

Issue #78: Incremental build performance dropped
Created: 2015-10-08T08:11:19Z
Hi,
I noticed that our incremental builds started to be considerably slower than they used to, so I ran webpack with --profile --progress and older versions of ts-loader to see if there are differences. It seems that v0.5.2 is twice as fast as the latest version. I'm unsure how to interpret the profiling data and the webpack source code is a complete mess, so it doesn't help much in that regard.
Here are the stats:
// ts-loader v0.5.2
379ms build modules   
19ms seal
39ms optimize
60ms hashing
35ms create chunk assets
2ms additional chunk assets 
0ms optimize chunk assets 
0ms optimize assets 
99ms emit
Hash: fdd096aa48ded051dda3
Version: webpack 1.12.2
Time: 639ms

// ts-loader v0.5.6
357ms build modules   
19ms seal
50ms optimize
51ms hashing
40ms create chunk assets
4ms additional chunk assets 
0ms optimize chunk assets 
826ms optimize assets
78ms emit
Hash: fdd096aa48ded051dda3
Version: webpack 1.12.2
Time: 1429ms

It looks like there is a lot of time spent in "optimize assets". I don't know what's causing this, but I have a feeling that ts-loader is using some extra dependencies now which may have the side-effect of enabling some webpack optimizations that are meant for production, not development.

Duplicate issue #255: Error Checks block increases incremental build time
Created: 2016-08-02T01:47:17Z
During ts-loader's after-plugin callback, the error checks take a ton of time per incremental build. In the code base I'm currently working with, error checks suck up over 6 seconds of incremental build  time.
All typescript files by default are currently checked for errors. I'm proposing that we add a regex to exclude files solely for error checks for incremental build time optimization.
My current build time went from 8s to 2s on average through a prototype of this change.

Closing comment (2016-08-02T23:24:45Z): Duplicate of #78
Repository: TypeStrong/ts-loader

Issue #926: [Question/Feature Request] Specify different tsconfigs for different instances.
Created: 2019-04-25T15:01:32Z
We can specify different instances of ts-loader like this:
module: {
        rules: [
            // this will fail if both files are passed through the same instance
            { test: /a\.ts$/, loader: '../../index.js' },
            { test: /b\.ts$/, loader: '../../index.js', options: { instance: 'different' } }
        ]
}

but is there a way that I can have each of these instances use a different tsconfig? Perhaps one set of files is allowed to have dom related types and another set of files is meant to be universal and so should not have any dom types.
In my use case files from both sets need to end up in the final 1 bundle.

Duplicate issue #865: How to use current directory tsconfig.json?
Created: 2018-10-31T18:50:05Z
I currently have two folders src and sw (which would be a different environment, in this case a service worker) and I want to use different tsconfig.json files for each folder. Although ts-loader picks one tsconfig.json file, ignore the other and then use the picked one to compile all files of both directories. How can I fix that behavior? I have a different tsconfig.json file inside each of these projects.
Sorry if this is a duplicate, I already searched a few issues in this repository but none of them fixed my problem.

Closing comment (2019-04-25T15:11:46Z): Related to #926. @johnnyreilly you pointed out that @VictorQueiroz should use 2 different instances, but he also asked how we can use a different tsconfig for each instance.
Repository: TypeStrong/ts-loader

Issue #929: Breaking change in micromatch 4 in ts-loader 5.4.6
Created: 2019-05-06T10:24:26Z
Expected Behaviour
Everything should work fine because it is just a patch, not a breaking release.
Actual Behaviour
I am having this log when trying to upgrade to version 5.4.6
[root]\node_modules\ts-loader\node_modules\micromatch\index.js:44
    let isMatch = picomatch(String(patterns[i]), { ...options, onResult }, true);
                                                   ^^^

SyntaxError: Unexpected token ...

Steps to Reproduce the Problem
Here is my webpack.config.js
const TsconfigPathsPlugin = require('tsconfig-paths-webpack-plugin');

module.exports = {
  resolve: {
    extensions: ['.ts', '.js'],
    plugins: [new TsconfigPathsPlugin({})],
  },
  module: {
    rules: [
      {
        test: /\.ts$/,
        exclude: [/node_modules/],
        use: [
          {
            loader: 'ts-loader',
          },
        ],
      },
    ],
  },
};
Location of a Minimal Repository that Demonstrates the Issue.
Refer to this PR: penta-jelly/re-radio#167
Follow these steps will produce this error

Checkout branch.
Run cd e2e
Run npm ci
Run npm run cypress:open
Open any test showing up in Cypress panel.
Then you can see the error log described above.

CI build result: https://circleci.com/gh/penta-jelly/re-radio/802

Duplicate issue #931: build bug with new version
Created: 2019-05-07T20:11:14Z
Expected Behaviour
it builds properly
Actual Behaviour
it fails with this warning
./cypress/integration/bugtest/example.spec.ts
Module build failed (from ./node_modules/ts-loader/index.js):
/some_path/node_modules/ts-loader/node_modules/micromatch/index.js:44
    let isMatch = picomatch(String(patterns[i]), { ...options, onResult }, true);
                                                   ^^^

SyntaxError: Unexpected token ...

Steps to Reproduce the Problem

a new cypress project, try adding typescript like in their example
npm run cypress:open

If your ts-loader version is > 5.4.5 it will break. I confirmed switching to 5.4.5 it does not break
It appears to be caused by: https://github.com/TypeStrong/ts-loader/pull/928/files#diff-b9cfc7f2cdf78a7f4b91a753d10865a2R57
and I see similar issues on other projects that may be realted: micromatch/micromatch#159 or BrowserSync/browser-sync#1682

Closing comment (2019-05-19T02:11:43Z): Closing as duplicate of #929. Thanks @B3zo0 👍
Repository: TypeStrong/ts-loader

Issue #388: Cannot use ag-grid with ts-loader >= 0.9.3
Created: 2016-11-21T16:46:29Z
When using ag-grid and ts-loader >= 0.9.3 with allowJs set to true, I get lots of error like this :
Module '"[...]/node_modules/ag-grid/main"' has no exported member '[...]'.

It's fine with ts-loader 0.9.2
Maybe it's related to this issue: #250
Since ag-grid use the typings field as well https://github.com/ceolter/ag-grid/blob/master/package.json#L9

Duplicate issue #401: "allowJs": true leads to error in decorators "error TS1240: Unable to resolve signature of property decorator when called as an expression."
Created: 2016-12-05T15:56:57Z
TypeScript 2.0.10
ts-loader 1.2.2
Webpack 1.13.2
When using decorators from https://github.com/mobxjs/serializr library I see error "error TS1240: Unable to resolve signature of property decorator when called as an expression."
manual run tsc also works fine.
Regression introduced in v0.9.3
0.9.2 works fine!
I created minial repository to show the error: https://github.com/pqr/ts-loader-issue-401

Closing comment (2016-12-05T16:09:18Z): Possibly related to #388
Could you try the amend suggested there and see if that resolves your issue as well?
Repository: TypeStrong/ts-loader

Issue #316: [Compiler Options] Account for `allowJs` compiler option
Created: 2016-10-14T19:51:37Z
Currently, even though the allowJs compiler option has been defined in a tsconfig.json or via the ts.compilerOptions config, JavaScript modules will not be found. I have resolved this issue, at least for my needs, by changing line 95 in index.ts.
Original: const scriptRegex = /\.tsx?$/i;
Changed: const scriptRegex = /\.[jt]sx?$/i;
I haven't ran into any issues yet. If anyone has time to fully test this use case out. I would greatly appreciate your efforts. I currently don't have time to dig into this for a few weeks. There may other cases in the source code where the file extension match needs to take into account the allowJs option as well.

Duplicate issue #388: Cannot use ag-grid with ts-loader >= 0.9.3
Created: 2016-11-21T16:46:29Z
When using ag-grid and ts-loader >= 0.9.3 with allowJs set to true, I get lots of error like this :
Module '"[...]/node_modules/ag-grid/main"' has no exported member '[...]'.

It's fine with ts-loader 0.9.2
Maybe it's related to this issue: #250
Since ag-grid use the typings field as well https://github.com/ceolter/ag-grid/blob/master/package.json#L9

Closing comment (2016-11-28T17:24:53Z): Related to #316 cc @dschnare
Repository: TypeStrong/ts-loader

Issue #249: Writes a log message to stderr even when everything is OK
Created: 2016-07-18T15:46:53Z
When ts-loader starts up, it logs messages like this to stderr:
ts-loader: Using typescript@1.8.10 and /some/path/tsconfig.json

This is because the log function calls console.log.apply(console, message), and the console variable is overridden as follows:
var console = new Console(process.stderr);

I know most of the log values outputted by ts-loader are errors, but the Using typescript@... message isn't an error. Logging it to stderr isn't great, because many apps are configured to treat stderr output as actual errors (and write it to a DB, email an administrator, etc.)
I am aware this can be suppressed by setting silent to true, but then this suppresses other potentially useful error information.
Would it be possible not to log the Using typescript@... to stderr, but still log other messages to stderror?

Duplicate issue #311: Status code of log message wrong
Created: 2016-10-12T13:15:09Z
Hey,
first of all: this is a minor thing and just annoying but the log output gives a wrong status code for the ls-load output:
[ERROR] ts-loader: Using typescript@2.0.3 and /workspace/cool-project/src/main/resources/tsconfig.json
It was already mentioned in other projects like eirslett/frontend-maven-plugin#382
Would be really cool to see this fixed to have a clean output.

Closing comment (2016-10-12T13:31:19Z): Closing as duplicate of #249
Repository: TypeStrong/ts-loader

Issue #111: Impossible to emit CommonJS modules when targeting ES6
Created: 2015-11-28T16:22:28Z
It seems that the following line is not necessary anymore with TypeScript 1.7:

  
    
      ts-loader/index.ts
    
    
         Line 282
      in
      ff15e76
    
  
  
    

        
          
           compilerOptions.module = 0 /* None */; 
        
    
  


Removing it would allow us to target ES6 while still emitting CommonJS modules.

Duplicate issue #132: TypeScript compiler option "moduleResolution" is not inferred as it is by `tsc`
Created: 2016-01-06T03:24:53Z
tsc will infer that moduleResolution: "node" if I have module: "commonjs" in my tsconfig.json, even if I also have target: "ES6" (it won't default to node-style moduleResolution if module is set to "es6" and target is also set to "ES6").
However, when compiling with ts-loader via webpack, I have to explicitly add moduleResolution: "node" to my tsconfig file to avoid "Cannot find module 'whatever'" errors in the output.
Adding that line, "moduleResolution": "node" is trivial. Figuring out that I need to add it, to resolve errors that webpack + ts-loader was throwing at me, was frustrating. I would expect ts-loader's (default) behavior to match tsc's (default) behavior, particularly when the ts-loader log message says it's using exactly the same tsconfig file that tsc is using.

Closing comment (2016-01-10T01:53:07Z): I believe this is related to #111. Basically TypeScript's logic is if module: "commonjs", then moduleResolution: "node" is inferred (see here). However, ts-loader currently does some magic where if target: "ES6" is set then module: "commonjs" is ignored and module: "none" is used instead. This used to be desirable because otherwise TypeScript would throw an error. However, that is no longer the case, so I believe once #111 is fixed this will be as well.
Repository: VREMSoftwareDevelopment/WiFiAnalyzer

Issue #117: User defined colors/theme
Created: 2017-06-21T22:39:41Z
References:

Contrasting colors for 2.5GHz and 5GHz channels.
Contrasting colors for WEP, WPS, and open
High contrast theme
Black OLED Theme

Duplicate issue #183: Version info background dark
Created: 2018-06-01T00:47:05Z
It is hard to read the version number, because it is black on gray, instead of black on white

Closing comment (2018-06-01T11:33:17Z): Light Theme expected behavior.
Duplicate #117
Repository: VREMSoftwareDevelopment/WiFiAnalyzer

Issue #99: F-Droid Key Changed?
Created: 2017-04-20T22:38:53Z
I'm getting a message on F-Droid saying that I need to uninstall the app and reinstall it because it was signed by a different key. Was a different key used or was there a security breach?

Duplicate issue #263: v2.0.8 not updated on F-Droid
Created: 2019-09-09T16:20:37Z
2.0.8 released on 8/31 but as of today 9/9 the version still shows 2.0.7 on F-Droid

Closing comment (2019-09-20T22:05:23Z): @user8446 duplicate #99
Repository: VREMSoftwareDevelopment/WiFiAnalyzer

Issue #116: Aliases for the APs
Created: 2017-06-19T19:47:15Z
It would be nice to give some names for specific APs to keep them organised (e.g. positions of the AP).
Specially for environments with multi-AP but one SSID.

Duplicate issue #149: Auto download and import of aliasfile 
Created: 2018-01-29T14:11:31Z
hi.
is it possible to add on option to insert a url for the alias list?
An option that automatically check if the list is older than a specific time to reload and import  after opening the app?
Greetz,
Manu.

Closing comment (2018-01-29T15:57:31Z): Duplicate #116
Repository: VREMSoftwareDevelopment/WiFiAnalyzer

Issue #36: Scrollable View changes position on Device Rotation
Created: 2016-06-21T08:26:08Z
When I perform this sequence of events, the scroll view on screen goes back to the top:

Open Side Drawer
Click on About
Scroll Down
Orientation Change

Duplicate issue #255: Unexpected behaviours after a screen orientation change (reported by activity)
Created: 2019-08-06T14:09:32Z
I developed an automatic test case generation tool and it detected these problems in your app.
I would like to know if you consider them as failures and, if not, why. Thanks for your collaboration.

When I change the orientation of the device screen, MainActivity changes its state. Below there are different examples: the screenshots were taken before and after the screen orientation change and they are paired (before, after), (before, after) ...

-- first case --
The size of the TextView changes and becomes bigger


-- second case --
Tiks of the X axis appear



When I change the orientation of the device screen, the Dialog disappears in AboutActivity

Closing comment (2019-08-06T21:58:03Z): Duplicate #36, #77 & #78

Android creates a new view when switching orientation. It is intended.
Low Priority bug.
It would be great if you can provide a pull request to fix it.

Btw, thanks for reporting 👍
Repository: VREMSoftwareDevelopment/WiFiAnalyzer

Issue #238: Android Q Wifi scan throttling
Created: 2019-05-24T09:44:00Z
According to this comment on the Android issue tracker, Android Q will include an option to disable throttling again, though it's not clear whether it might also appear in the GUI developer options, or whether it can only be set programatically via adb, respectively using root access.

Duplicate issue #315: Feature Request: option to automatically "disable wifi scan throttling" via root permissions
Created: 2020-11-03T03:46:23Z
An option to allow for disabling and re-enabling the wifi scan throttling, automatically, if the app has root permissions granted.
I couldn't find a specific example since I'm not a software developer, but I found this (for another setting within developer options) which may help to create the appropriate code:
Process proc = Runtime.getRuntime().exec(new String[]{"su","pm grant YOUR_APP_PACKAGE_NAME android.permission.WRITE_SECURE_SETTINGS", "settings put secure mock_location 1"});

proc.waitFor();

int value = Settings.Secure.getInt(getContentResolver(), Settings.Secure.ALLOW_MOCK_LOCATION);

SOP.OUT("mock_location::::::::::::::::::::::::::::::::: " + value);

With that, an "EXIT" button and/or an exit sequence (by using the Android "back" soft key to back out of the app) which would also re-enable the scan throttling upon closing the app.
This would be an excellent way to preserve battery life, automatically.

Closing comment (2020-11-08T13:59:14Z): Duplicate #238
Repository: VREMSoftwareDevelopment/WiFiAnalyzer

Issue #365: Ability to check how long time the found devices work - Beacon frame
Created: 2021-12-27T18:19:23Z
In the Beacon frame that is sent by devices via WiFi, information is sent how long time the device works. The field is 8 bytes long and the value shown is expressed in microseconds.

This can be useful additional information about found WiFi networks in application.
More details you can read here.
Note that some devices (e.g. managed by ISP operators) may have their timestamp always set to 0, so then you should also handle this case.

Duplicate issue #367: Display Vendor Specific Information Elements as possible since API Level 30
Created: 2022-01-29T14:15:21Z
It would be nice if the App displayed the vendor specific IEEE 802.11 information elements that were found in the WiFi Beacons. Android's API Level 30 introduced ScanResult.getInformationElements(), which can be used to query this information.

Closing comment (2022-02-19T12:49:00Z): I think it is related to #365
Repository: VREMSoftwareDevelopment/WiFiAnalyzer

Issue #271: Labels in the tabbed menu do not scale nicely when using Android native scaling
Created: 2019-12-07T14:35:16Z
Describe the bug
Labels in the tabbed menu do not scale nicely when using Android native scaling. The label turns into multiline, where 2nd lind and beyond gets hidden. Been like this for multiple releases back in time.
To Reproduce
Scale Android system to more than 100%.
Expected behavior
Labels should either scale or stay the same size. They should not be cut of/ missing, like the screenshot.
Screenshots

Note
App v2.1.1
Additional context
Add any other context about the problem here.
Provide Device/Android OS information
OnePlus 6 with Oxygen OS 10.0.1 (Android 10), no mods.

Duplicate issue #283: Last part of text on some visible and on many selected items ("Access Points", "Channel Rating", "Channel Graph", "Time Graph") aren't shown
Created: 2020-02-19T19:42:16Z
Good day
Firstly, again, and again, I want to thank you very much for creating "WiFiAnalyzer"!
It's awesome software!
In WiFiAnalyzer 2.1.1 and older: WiFiAnalyzer 2.0.8, WiFiAnalyzer 2.0.7, WiFiAnalyzer 2.0.5,
"Access Points", "Channel Rating", "Channel Graph", "Time Graph" items from menu were also added as shortcuts to newly created bottom menu.
Last part of text on some visible items and on many selected items aren't shown.
STR:

Press "Channel Rating" item in bottom menu
and see only "Channel" text on "Channel Rating" item

In other languages, e.g. "Polish",
"Access Points" (ENG) = "Punkty dostępu" (PL)
are shown as only "Punkty".
I'm using WiFiAnalyzer 2.1.1 on Android 6.0.1 on Sony Xperia Z3 Compact and LG Spirit.
Best regards

Closing comment (2020-02-22T14:52:26Z): Please use provided templates to report issues (Default or Bug report template) or request features (Feature request template).
Please do not forget to fill all questions/topics in the templates.
Duplicate #271, #257, #264
Repository: VREMSoftwareDevelopment/WiFiAnalyzer

Issue #257: A small GUI correction - Access Point in the Polish language version
Created: 2019-09-01T18:26:34Z
The name "Punkty"  in the Polish language version is aligned to the left which looks less good than the name would be centered to the location of the WiFi icon.
App version: 2.0.8. - 49GS(9-28)

Duplicate issue #264: 2:1 screen
Created: 2019-09-11T20:21:56Z
How to report a bug
Please search issues (open and closed) to see the issues has already been reported.
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Note
Some behaviour only occurs on certain devices or versions of Android 8.1, MIUI 10.3.1.0, please provide the following screenshots/information Device/Android OS (Settings →
Additional context
Add any other context about the problem here.
Provide Device/Android OS information

Closing comment (2019-09-11T21:57:29Z): Duplicate  #257
Repository: VSCodeVim/Vim

Issue #5180: getLineLength() called with out-of-bounds line 223
Created: 2020-09-12T23:52:52Z
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

VSCodeVim version: 1.16.3
Stack trace
Error: getLineLength() called with out-of-bounds line 223
    at Function.getLineLength (/home/saulo/.vscode/extensions/rebornix.999-test-vim-1.16.3/out/extension.js:1:22162)
    at l.getLineEnd (/home/saulo/.vscode/extensions/rebornix.999-test-vim-1.16.3/out/extension.js:1:13712)
    at F.handleSelectionChange (/home/saulo/.vscode/extensions/rebornix.999-test-vim-1.16.3/out/extension.js:9:468948)
    at Object.promise (/home/saulo/.vscode/extensions/rebornix.999-test-vim-1.16.3/out/extension.js:9:235726)
    at Object.runTasks (/home/saulo/.vscode/extensions/rebornix.999-test-vim-1.16.3/out/extension.js:9:620104)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:94:5)

Duplicate issue #5466: getLineLength() called with out-of-bounds line 120
Created: 2020-10-21T18:21:27Z
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

VSCodeVim version: 1.17.1
Stack trace
Error: getLineLength() called with out-of-bounds line 120
    at Function.getLineLength (/Users/alou/.vscode/extensions/vscodevim.vim-1.17.1/out/extension.js:1:22225)
    at l.getUpWithDesiredColumn (/Users/alou/.vscode/extensions/vscodevim.vim-1.17.1/out/extension.js:1:11622)
    at l.getLeftThroughLineBreaks (/Users/alou/.vscode/extensions/vscodevim.vim-1.17.1/out/extension.js:1:10872)
    at Object.t.statusBarCommandText (/Users/alou/.vscode/extensions/vscodevim.vim-1.17.1/out/extension.js:1:31413)
    at Object.updateShowCmd (/Users/alou/.vscode/extensions/vscodevim.vim-1.17.1/out/extension.js:1:40543)
    at F.handleKeyEvent (/Users/alou/.vscode/extensions/vscodevim.vim-1.17.1/out/extension.js:9:472169)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:94:5)
    at Object.promise (/Users/alou/.vscode/extensions/vscodevim.vim-1.17.1/out/extension.js:9:235740)
    at Object.runTasks (/Users/alou/.vscode/extensions/vscodevim.vim-1.17.1/out/extension.js:9:621914)

Closing comment (2020-10-26T18:58:46Z): Duplicate of #5180, please post repro steps there
Repository: VSCodeVim/Vim

Issue #6343: Failed to handle key=<Esc>. Cannot read property 'previousMode' of undefined
Created: 2021-03-24T16:33:27Z
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

VSCodeVim version: 1.19.1
Stack trace
TypeError: Failed to handle key=<Esc>. Cannot read property 'previousMode' of undefined
    at I.updateView (/home/jaime_m_h/.vscode/extensions/vscodevim.vim-1.19.1/src/mode/modeHandler.ts:1171:50)
    at I.handleKeyAsAnAction (/home/jaime_m_h/.vscode/extensions/vscodevim.vim-1.19.1/src/mode/modeHandler.ts:657:16)
    at process.handledAsAction (internal/process/task_queues.js:97:5)
    at I.async [as handleKeyEvent] (/home/jaime_m_h/.vscode/extensions/vscodevim.vim-1.19.1/src/mode/modeHandler.ts:469:11)
    at Object.promise (/home/jaime_m_h/.vscode/extensions/vscodevim.vim-1.19.1/extensionBase.ts:632:27)
    at Object.runTasks (/home/jaime_m_h/.vscode/extensions/vscodevim.vim-1.19.1/src/taskQueue.ts:36:26)

Duplicate issue #7029: Failed to handle key=/. Cannot read property 'previousMode' of undefined
Created: 2021-08-26T16:05:41Z
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

VSCodeVim version: 1.21.6
Stack trace
TypeError: Failed to handle key=/. Cannot read property 'previousMode' of undefined
    at I.updateView (/Users/alekseidubrovskii/.vscode/extensions/vscodevim.vim-1.21.6/src/mode/modeHandler.ts:1170:50)
    at I.handleKeyAsAnAction (/Users/alekseidubrovskii/.vscode/extensions/vscodevim.vim-1.21.6/src/mode/modeHandler.ts:667:16)
    at process.handledAsAction (internal/process/task_queues.js:93:5)
    at I.text [as handleKeyEvent] (/Users/alekseidubrovskii/.vscode/extensions/vscodevim.vim-1.21.6/src/mode/modeHandler.ts:472:11)
    at /Users/alekseidubrovskii/.vscode/extensions/vscodevim.vim-1.21.6/extensionBase.ts:370:73

Closing comment (2021-08-30T19:35:02Z): Duplicate of #6343
Repository: VSCodeVim/Vim

Issue #1806: The extension does not respect vscode's selection
Created: 2017-06-05T04:17:57Z
Environment:

VSCode Version: 1.12.2
VsCodeVim Version: 0.8.4
OS: Linux

What happened:
Using editor.action.smartSelect.grow to selection a string, then press c, it does not modify the whole selected text.
What did you expect to happen: The whole selected text should be modified. (Actually when I selection anything it is expected to enter visual mode. However it remains in normal mode. Even if I enter visual mode manually before executing editor.action.smartSelect.grow, the extension does not respect the selection.)

Duplicate issue #2942: Selection usage in Visual Mode
Created: 2018-08-07T12:36:21Z
Can not use these command or extentions in Visual Mode:

command: editor.action.smartSelect.grow
extention: expand-region
extention: very-smart-select
extention: vscode-expand-selection-to-scope

Closing comment (2019-09-03T19:40:41Z): More or less a duplicate of #1806
Repository: VSCodeVim/Vim

Issue #2472: Implement `:m[ove]` command
Created: 2018-03-24T18:09:53Z
FEATURE REQUEST
Hi there,
I've perused the road map and couldn't find :copy and :move commands.  I also couldn't find a decent way to replicate these using native VS Code commands.
I believe that any Vim user would love to see these implemented in your already fantastic extension.
"The vim :copy command (and its shorthand :t) lets us duplicate one or more lines from one part of the document to another, while the :move command lets us place them somewhere else in the document."
The format of the copy command goes like this:
:[range]copy {address} 
The :move command looks similar to the :copy command:
:[range]move {address} 
Reference:
“Practical Vim: Edit Text at the Speed of Thought.” Practical Vim: Edit Text at the Speed of Thought, by Drew Neil, The Pragmatic Bookshelf, 2012, pp. 59–61.
Environment:


Extension (VsCodeVim) version: 0.11.2
VSCode version:  1.21.1 (1.21.1)
OS version:  10.13.4 Beta (17E182a)

Duplicate issue #6638: Move selected code up/down using `j`/`k`
Created: 2021-05-19T21:05:23Z
In VSCode it is possible to move a selected code up or down using the Alt+Arrow key.
Is it possible to create some mapping that will allow me to move the selected down up/down using something like Alt-j/Alt-k? (Just wanna avoid the arrow kays)
Thanks

Closing comment (2021-10-14T18:13:29Z): Yeah, @w-cantin's suggestion is the best workaround for now. Marking as duplicate of #2472, because supporting :m[ove] would also allow you to do this.