🎯 MapView v2.0 - Global Deployment Ready

 MAJOR FEATURES:
• Auto-zoom intelligence với smart bounds fitting
• Enhanced 3D GPS markers với pulsing effects
• Professional route display với 6-layer rendering
• Status-based parking icons với availability indicators
• Production-ready build optimizations

🗺️ AUTO-ZOOM FEATURES:
• Smart bounds fitting cho GPS + selected parking
• Adaptive padding (50px) cho visual balance
• Max zoom control (level 16) để tránh quá gần
• Dynamic centering khi không có selection

🎨 ENHANCED VISUALS:
• 3D GPS marker với multi-layer pulse effects
• Advanced parking icons với status colors
• Selection highlighting với animation
• Dimming system cho non-selected items

🛣️ ROUTE SYSTEM:
• OpenRouteService API integration
• Multi-layer route rendering (glow, shadow, main, animated)
• Real-time distance & duration calculation
• Visual route info trong popup

📱 PRODUCTION READY:
• SSR safe với dynamic imports
• Build errors resolved
• Global deployment via Vercel
• Optimized performance

🌍 DEPLOYMENT:
• Vercel: https://whatever-ctk2auuxr-phong12hexdockworks-projects.vercel.app
• Bundle size: 22.8 kB optimized
• Global CDN distribution
• HTTPS enabled

💾 VERSION CONTROL:
• MapView-v2.0.tsx backup created
• MAPVIEW_VERSIONS.md documentation
• Full version history tracking
This commit is contained in:
2025-07-20 19:52:16 +07:00
parent 3203463a6a
commit c65cc97a33
64624 changed files with 7199453 additions and 6462 deletions

View File

@@ -0,0 +1,220 @@
# import/no-restricted-paths
<!-- end auto-generated rule header -->
Some projects contain files which are not always meant to be executed in the same environment.
For example consider a web application that contains specific code for the server and some specific code for the browser/client. In this case you dont want to import server-only files in your client code.
In order to prevent such scenarios this rule allows you to define restricted zones where you can forbid files from being imported if they match a specific path.
## Rule Details
This rule has one option, which is an object containing all `zones` where restrictions will be applied, plus an optional `basePath` used to resolve relative paths within each zone.
The default for `basePath` is the current working directory.
Each zone consists of a `target`, a `from`, and optional `except` and `message` attributes.
- `target` - Identifies which files are part of the zone. It can be expressed as:
- A simple directory path, matching all files contained recursively within it
- A glob pattern
- An array of any of the two types above
- *Example: `target: './client'` - this zone consists of all files under the 'client' dir*
- `from` - Identifies folders from which the zone is not allowed to import. It can be expressed as:
- A simple directory path, matching all files contained recursively within it
- A glob pattern
- An array of only simple directories, or of only glob patterns (mixing both types within the array is not allowed)
- *Example: `from: './server'` - this zone is not allowed to import anything from the 'server' dir*
- `except` - Optional. Allows exceptions that would otherwise violate the related `from`. Note that it does not alter the behaviour of `target` in any way.
- If `from` is an array of glob patterns, `except` must be an array of glob patterns as well.
- If `from` is an array of simple directories, `except` is relative to `from` and cannot backtrack to a parent directory.
- *Example: `except: './server/config'` this zone is allowed to import server config, even if it can't import other server code*
- `message` - Optional. Displayed in case of rule violation.
*Note: The `from` attribute is NOT matched literally against the import path string as it appears in the code. Instead, it's matched against the path to the imported file after it's been resolved against `basePath`.*
### Examples
Given this folder structure:
```pt
.
├── client
│ ├── foo.js
│ └── baz.js
└── server
└── bar.js
```
And this configuration:
```json
{
"zones": [
{
"target": "./client",
"from": "./server"
}
]
}
```
:x: The following is considered incorrect:
```js
// client/foo.js
import bar from '../server/bar';
```
:white_check_mark: The following is considered correct:
```js
// server/bar.js
import baz from '../client/baz';
```
---------------
Given this folder structure:
```pt
.
├── client
│ └── ...
└── server
├── one
│ ├── a.js
│ └── b.js
└── two
└── a.js
```
And this configuration:
```json
{
"zones": [
{
"target": "./server/one",
"from": "./server",
"except": ["./one"]
}
]
}
```
:x: The following is considered incorrect:
```js
// server/one/a.js
import a from '../two/a'
```
:white_check_mark: The following is considered correct:
```js
// server/one/a.js
import b from './b'
```
---------------
Given this folder structure:
```pt
.
└── client
├── foo.js
└── sub-module
├── bar.js
└── baz.js
```
And this configuration:
```json
{
"zones": [
{
"target": "./client/!(sub-module)/**/*",
"from": "./client/sub-module/**/*",
}
]
}
```
:x: The following is considered incorrect:
```js
// client/foo.js
import a from './sub-module/baz'
```
:white_check_mark: The following is considered correct:
```js
// client/sub-module/bar.js
import b from './baz'
```
---------------
Given this folder structure:
```pt
.
├── one
│ ├── a.js
│ └── b.js
├── two
│ ├── a.js
│ └── b.js
└── three
├── a.js
└── b.js
```
And this configuration:
```json
{
"zones": [
{
"target": [
"./two/*",
"./three/*"
],
"from": [
"./one",
"./three"
]
}
]
}
```
:white_check_mark: The following is considered correct:
```js
// one/b.js
import a from '../three/a'
import a from './a'
```
```js
// two/b.js
import a from './a'
```
:x: The following is considered incorrect:
```js
// two/a.js
import a from '../one/a'
import a from '../three/a'
```
```js
// three/b.js
import a from '../one/a'
import a from './a'
```